🖥 Python `multiprocessing` и ловушка, о которую бьются даже опытные…
🖥 Python `multiprocessing` и ловушка, о которую бьются даже опытные разрабы
В старых версиях Python на Linux multiprocessing часто стартовал процессы через fork().
И вот где начинается боль.
После fork() в дочернем процессе остаётся только один поток. Но состояние мира копируется как было:
* lock мог быть захвачен
* file descriptors всё ещё указывают на те же файлы
* сокеты и буферы могут оказаться в странном состоянии
* другой поток, который должен был отпустить lock, уже не существует
Это поведение POSIX.
Поэтому fork + threads - классический рецепт для редких, мерзких deadlock’ов.
Хорошая практика: для multiprocessing чаще выбирать spawn или forkserver, особенно если в приложении есть потоки, логгеры, сетевые клиенты или фоновые воркеры.
Важная поправка: начиная с Python 3.14, на POSIX дефолтный start method поменяли с fork на forkserver, как раз чтобы избежать части этих проблем.
Мелочь в настройке старта процесса. Огромная разница в стабильности.
В старых версиях Python на Linux multiprocessing часто стартовал процессы через fork().
И вот где начинается боль.
После fork() в дочернем процессе остаётся только один поток. Но состояние мира копируется как было:
* lock мог быть захвачен
* file descriptors всё ещё указывают на те же файлы
* сокеты и буферы могут оказаться в странном состоянии
* другой поток, который должен был отпустить lock, уже не существует
Это поведение POSIX.
Поэтому fork + threads - классический рецепт для редких, мерзких deadlock’ов.
Хорошая практика: для multiprocessing чаще выбирать spawn или forkserver, особенно если в приложении есть потоки, логгеры, сетевые клиенты или фоновые воркеры.
Важная поправка: начиная с Python 3.14, на POSIX дефолтный start method поменяли с fork на forkserver, как раз чтобы избежать части этих проблем.
Мелочь в настройке старта процесса. Огромная разница в стабильности.