Асинхронно в любом случае будет "в порядке очереди событий, как тебе ядро сгенерит". select не беру в рассмотрение. Или мы уже асинк не через epoll/kqueue научились делать? Синхронно - это "я жду ответа", а как меня там ОС будет менеджерить - это проблемы ОС, а не мои.
Понедельник, 09 февраля 2015, 18:55 +04:00 от Andrey Kovbovich <[email protected]>: >Прошу развернуть свою мысль. Если для тебя асинхронно значит >мультиплексирование коннектов через один канал, то наверное мы о разном >немного. > >понедельник, 9 февраля 2015 г. пользователь [email protected] написал: >>Неверно в принципе, ну да ладно... >> >>Понедельник, 09 февраля 2015, 17:09 +04:00 от Andrey Kovbovich < >>[email protected] >: >>>Асинхронно - это когда несколько потоков исполнения работают как им >>>возблагорассудиться, а синхронно - это когда потоки работают в соответствии >>>некому генератору квантов логического времени >>> >>>понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky написал: >>>>> Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и >>>>> больше уже памяти нет. >>>>Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному >>>>приложению эта память не понадобится? Может, и синхронному не нужна? >>>>-- >>>>Moscow.pm mailing list >>>>[email protected] | http://moscow.pm.org >>>-- >>>Moscow.pm mailing list >>>[email protected] | http://moscow.pm.org >> >>Собственно тут вроде-бы еще не проскальзывала мысль, что асинхронность, при >>условии достаточности ресурсов - это всегда медленнее чем синхронность. >>Например: Я зажевал в один поток все сообщения, раздал запросы на данные и >>обрабатываю результаты.... Пока я обрабатываю один результат, остальные >>стоят. В случае с синхронным форком такого-бы не было (у нас много ядер). >> >>Проблема назревает когда у нас бекэнд (то, что отвечает на запросы), >>обрабатывает запрос долго. Но в этом случае какая, нафиг, кому разница - где >>делается "асинхронность" - у нас в лупе или в ядре при свитче контекста. Бек >>все-равно дольше... >> >>Асинхронность нужна в некоторых случаях: >>- Если у вас стоимость свитча контекста гораздо дороже ответа от бэка (по >>времени), но при переходе на асинк у вас еще будет дофига ресурсов ЦПУ (так >>как свитч контекста - это ЦПУ задача). >>- Если у вас асинк дает другие преимущества (в то числе и "потому что его >>умеют готовить разработчики, а вот с форком им сложно"). >>- Если у вас задача "обработать данные, зная что у вас в очереди всегда есть >>следующие задачи". Допустим быстрое преобразование фурье с отсылкой >>результатов далее по конвееру. (Привет SETI@Home) Вот тогда - да. Тогда есть >>у вас CPU баунд задача и вам важны такты процессора. >> >>На практике мы всегда боимся 1го, но зачастую протормозы в беках гораздо >>больше. >> >>ЗЫ: Тоже поучаствовать решил. >-- >Moscow.pm mailing list >[email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
