Pull to refresh

Comments 7

  • Процессы в чистом виде непригодны для подобного класса задач, слишком большой оверхед на создание процесса и его убийство, взаимодействовать с ОС так часто - дорогое удовольствие.

ИМХО, процессы отлично работают для таких задач, только писать нужно немножко по другому. Если мы хотим скажем обрабатывать что-то в нескольких параллельных ветках, то пишем воркер, который будучи запущенным, ждет на вход сообщение с входной информацией, обработав ее, он посылает сообщение с результатом и ждет следующего сообщения. В начале работы запускаем сколько хотим воркеров, в конце работы завершаем их работу.

Таким образом создание процессов происходит один раз для каждого процесса, а все преимущества процессов остаются.

Спасибо за комментарий!

Можете привести пример кода, как можно под задачу из статьи адаптировать процессы чтобы они работали эффективнее?

В качестве примера после комментария@evgenyk - мне лично вспоминается svchost.exe и services.exe

Получается, при наличии асинхронности потоки полностью неактуальны для любых задач?

Если я правильно помню, питоньи либы написанные на Си имеют возможность "отпустить" GIL, то есть какую-нибудь (условно!) функцию из numpy распараллелить по потокам, это может иметь смысл

Даже стандарный multiprocessing.pool не ограничен GIL. Его логика скорее как и у gc, упросить написание кода. Т.е. асинк простой и защищен разрабами языка, а вот pool уже предполагает что "тут все взрослые".

Sign up to leave a comment.

Articles