Но не понятно, для чего делать колбек, для таких целей

Ну так сделано в вайбе. Не лучшее на мой взгляд решение. Но простое и работает. Это проще, чем городить рендж и возвращать его.

и работа с таким коллбеком практически не отличается от работы с возвращаемым ренджем, так как коллбек выполняется синхронно

На вайбе писать очень легко и просто сложное параллельное IO, на эвентах получается адская лапша.

На вайбе писать очень легко и просто сложное параллельное IO, на эвентах получается адская лапша.

А ивенты тут причем?

Ну а начем работает твой libev или что ты там собрался использовать?

На вайбе писать очень легко и просто сложное параллельное IO, на эвентах получается адская лапша.

Ивенты все равно придется использовать, если хочешь делать компонентность/модульность, с минимальной связанностью

Ивенты все равно придется использовать, если хочешь делать компонентность/модульность, с минимальной связанностью

файберы от них по большей части избавляют, все внути ядра

Ну а начем работает твой libev или что ты там собрался использовать?

А, ты об этом

допустим у тебя сто файберов ждут ответа от разных источников. Ядро принимает ивенты о прибытии данных, само будит нужный файбер и передает ему эти данные.

вайбовские таски могут ожидать не только IO, но и чего угодно, сообщений от других тасков или вообще каких-нибудь твоих собственных условий.

Ты на каком языке кроме D пишешь? Я попробую тебе аналоги подобрать.

допустим у тебя сто файберов ждут ответа от разных источников. Ядро принимает ивенты о прибытии данных, само будит нужный файбер и передает ему эти данные.

Причем для файбера это выглядит просто как блокирующая операция. Это очень сильно облегчает написание кода. Синхронное оно кагбэ всегда проще асинхронного.

А боятся засрать систему тучей файберов не надо. На то они и файберы. Их, в отличие от потоков, можно спавнить тоннами.

если не ошибаюсь, с файберами есть один нюанс - размер стека. в 64битах можно в принципе ставить любой размер, но в 32-х уже довольн тесно и нужно следить что там у тебя в стеке

кроме того переключение файберов конечно легче чем переключение тредов, но все-равно не бесплатное

если не ошибаюсь, с файберами есть один нюанс - размер стека. в 64битах можно в принципе ставить любой размер, но в 32-х уже довольн тесно и нужно следить что там у тебя в стеке

Да, есть такой косяк. Я и в 64 битах ограничиваю. На рабочей системе я вырубил избыточное выделение памяти и, соответственно, OOM-киллер.

кроме того переключение файберов конечно легче чем переключение тредов, но все-равно не бесплатное

Да, небольшой оверхед есть. За удобство надо платить.

Оверхед реально маленький. Даже на МК часто используются аналоги.

Кстати кому еще, кроме древних систем нужны 32-бита?

Разве что embedded системы с огранниченными ресурсами

периодически на форуме кто-то пишет о сових проблемах на 32 битах, то есть кто-то использует

не знаю зачем честно говоря

на 32 битах и GC криво работает

да, на 32 битах течет сильнее

ИМХО все новые приложения уже давно должны писаться на 64-бита

Ты на каком языке кроме D пишешь? Я попробую тебе аналоги подобрать.

Я прекрасно понимаю как оно устроено

Ну а все таки на каком языке? А то что-то я сомневаюсь, вопросы то "новичковые".

вайбовские таски могут ожидать не только IO, но и чего угодно, сообщений от других тасков или вообще каких-нибудь твоих собственных условий.

Ну сообщение из другого файбера - это такое... Зачем?

Ну а все таки на каком языке? А то что-то я сомневаюсь, вопросы то "новичковые".

Какие вопросы?

Какие вопросы?

Да вот даже предыдущий :)

Зачем колбеки, если есть имитация синхронности?)))

Да вот даже предыдущий :)

Потому, что я не вижу в этом необходимости

Или "зачем нужны файберы для IO?"

Или "зачем нужны файберы для IO?"

Я такое спрашивал?

Потому, что я не вижу в этом необходимости

Ну это говорит всего лишь об узости твоего личного кругозора.

Ну это говорит всего лишь об узости твоего личного кругозора.

Ну как скажешь. Просто я знаю как это сделать без таких костылей.

Вот и все

И зачем это делать в файбе?

Вот например спросил

Ну как скажешь. Просто я знаю как это сделать без таких костылей.

Это не костыли. А сделать можно и вовсе на ассемблере и объявить все языки костылями. ?

Я и пример то с 7ю внешними запросами приводил, т.к. для этого не нужно руками стартовать 7 файберов и писать их ожидание...

Я и пример то с 7ю внешними запросами приводил, т.к. для этого не нужно руками стартовать 7 файберов и писать их ожидание...

Ага можно и без них, правда намного сложнее.

Нужно например сделать 10 запросов и протом склеить ответы один большой ответ.

Вот например спросил

А это, говорит о узкости твоего кругозора. Т.к. это я писал о биндинге сокета. И я не вижу и сейчас необходимости биндинге именно в файбере)))

Нужно например сделать 10 запросов и протом склеить ответы один большой ответ.

Я о том, что нет нормальной конструкции для этого! Которая имеется в тех же Обещаниях

Я и пример то с 7ю внешними запросами приводил, т.к. для этого не нужно руками стартовать 7 файберов и писать их ожидание...

руками стартовать это сделать сраный auto task = runTask({...}), а подождать task.wait()?

7 штук

И склеить их ответы

Ждать не 1 файб, а 7

Смекаешь? © Джек Воробей

А это, говорит о узкости твоего кругозора. Т.к. это я писал о биндинге сокета. И я не вижу и сейчас необходимости биндинге именно в файбере)))

Причем тут кругозор? Скорее может на так понял. Но я тоже не говорил о биндинге, а говорил о выполнении запроса

Я о том, что нет нормальной конструкции для этого! Которая имеется в тех же Обещаниях

Есть async если хочешь - http://vibed.org/api/vibe.core.concurrency/async

Ждать не 1 файб, а 7

Ну а как ты собрался параллельно делать 7 запросов?

можешь обернуть создание файбера в примитивную функцию в одно строку

Как продолжить выполнение своего файбера, когда получишь ответ на все 7 запросов?

Которые желательно выполнить паралельно

Например вот так: auto resp1 = async({ return requestHTTP("...").readAllUTF8(); }); auto resp2 = async({ return requestHTTP("...").readAllUTF8(); }); string result = resp1.getResult() ~ resp2.getResult();

тут два запроса выполняются параллеьно и склеивается результат

сами запросы будут выполнены внутри двух файберов.

а теперь тоже самое пожалуйста на голых сокетах и libev ?

Более низкоуровневый вариент: Task[] taskPool; taskPool ~= runTask({ // задача 1 }); taskPool ~= runTask({ // задача 2 }); // ждем выполнения всех задач foreach(task; taskPool) task.wait(); // продолжаем работу

или даже что-то типа auto results = waitAll(taskPool); не знаю есть оно в вайбе или нет

или даже что-то типа auto results = waitAll(taskPool); не знаю есть оно в вайбе или нет

Вот такого то и нет, как я понимаю)))

Более низкоуровневый вариент: Task[] taskPool; taskPool ~= runTask({ // задача 1 }); taskPool ~= runTask({ // задача 2 }); // ждем выполнения всех задач foreach(task; taskPool) task.wait(); // продолжаем работу

Это бред

Более низкоуровневый вариент: Task[] taskPool; taskPool ~= runTask({ // задача 1 }); taskPool ~= runTask({ // задача 2 }); // ждем выполнения всех задач foreach(task; taskPool) task.wait(); // продолжаем работу

Ты сперва ждёшь первый, потом второй и так далее

Это не асинхронно

Конечно, оно сделает именно то, что ты хочешь, но...

Например вот так: auto resp1 = async({ return requestHTTP("...").readAllUTF8(); }); auto resp2 = async({ return requestHTTP("...").readAllUTF8(); }); string result = resp1.getResult() ~ resp2.getResult();

А этот вариант, мне кажется, вообще не рабочий

ERROR: S client not available

Это бред

?

Ты сперва ждёшь первый, потом второй и так далее

Ты же попросил дождаться выполнения ВСЕХ файберов, как еще-то делать?

А этот вариант, мне кажется, вообще не рабочий

Тебе кажется. Он рабочий.

Кстати, так как runTask запускает файберы в том же потоке, что и запускающий файбер, то можно делать вот так без race conditions: Task[] taskPool; Result[] results; taskPool ~= runTask({ // задача 1 results ~= result; }); taskPool ~= runTask({ // задача 2 results ~= result; }); // ждем выполнения всех задач foreach(task; taskPool) task.wait(); // продолжаем работу

Тебе кажется. Он рабочий.

Да, скорее всего. Там гетРезалт реализует удержание, видимо

async возвращает future, если ты знаешь, что это такое. Если не знаешь то вот - https://ru.wikipedia.org/wiki/Futures_and_promises

Кстати кому еще, кроме древних систем нужны 32-бита?

У меня прога 32-битная, т.к. использует 200+ плагинов, написанных третьими лицами за много лет, и плагины те почти все 32-битные.

async возвращает future, если ты знаешь, что это такое. Если не знаешь то вот - https://ru.wikipedia.org/wiki/Futures_and_promises

Забавный ты)

Да, более не менее просто дожидаться всех. А одного из?

У меня прога 32-битная, т.к. использует 200+ плагинов, написанных третьими лицами за много лет, и плагины те почти все 32-битные.

Тяжело быть тобой :)

Забавный ты)

Ну может ты и правда не знаешь. В этом нет ничего плохого. Не знаешь - узнай!

Да, более не менее просто дожидаться всех. А одного из?

Просто task.wait()

Один из 7

Произвольный

что значит произвольный? рандомный что-ли?

Ну может ты и правда не знаешь. В этом нет ничего плохого. Не знаешь - узнай!

Читай выше. Я о Обещаниях писал. Что там это реализуется просто

Делаешь 7 запросов. Как только получаешь ответ от одного - продолжить выполнение

Не все ждёшь, а один из

Читай выше. Я о Обещаниях писал. Что там это реализуется просто

Ну мало ли что ты пишешь. Если знаешь то молодей. Я же не сказал, что ты не знаешь. Я на всякий случай.

Ну мало ли что ты пишешь. Если знаешь то молодей. Я же не сказал, что ты не знаешь. Я на всякий случай.

Вот я и написал, что ты забавный)))

Вот я и написал, что ты забавный)))

Я рад, что тебе весело :)

Я рад, что тебе весело :)

О, мне всегда весело

Делаешь 7 запросов. Как только получаешь ответ от одного - продолжить выполнение

То есть ты хочешь дождаться того кто первый сделал свой запрос и продолжить дальше?

То есть ты хочешь дождаться того кто первый сделал свой запрос и продолжить дальше?

Да

Как-то так

waitAny

Это реализуемо чуть сложнее, полагаю тут тебе промисы тоже не помогут. Но я могу накидать код с применением пересылки сообщений между файберами. Заодно узнаешь зачем оно нужно, ты же спрашивал.

под капотом это всё-равно делается с помощью колбэков. для ожидания “любого” все задачи выставляются на такой колбэк кторый просто завершает ожидание

Это реализуемо чуть сложнее, полагаю тут тебе промисы тоже не помогут. Но я могу накидать код с применением пересылки сообщений между файберами. Заодно узнаешь зачем оно нужно, ты же спрашивал.

В промисах это 1 строчка any

как только калбэк сработал двигаемся дальше

под капотом это всё-равно делается с помощью колбэков. для ожидания “любого” все задачи выставляются на такой колбэк кторый просто завершает ожидание

В Обещании - да

В файберах - нет