Re:Free-threaded CPython is ready to experiment with
by ignoramous on Saturday July 13, 2024 @12:32PM
(#40955012)
> The default for multiprocessing is still to fork (fortunately changing in 3.14)
If I may: Changing from fork to what?
Re:Free-threaded CPython is ready to experiment with
by thomasjudge on Saturday July 13, 2024 @02:15PM
(#40955764)
"In Python 3.14, the default will be changed to either “spawn” or “forkserver” (a mostly safer alternative to “fork”)."
Re:Free-threaded CPython is ready to experiment with
by lyu07282 on Saturday July 13, 2024 @02:22PM
(#40955821)
Same experiences, multiprocessing is such a pain in python. It's one of these things people think they can write production code in, but they just haven't run into all the ways their code was wrong so they figure out those bugs later in production.
As an aside I still constantly see side effects in imports in a ton of libraries (up to and including resource allocations).
Re:Free-threaded CPython is ready to experiment with
by coldtea on Saturday July 13, 2024 @09:01PM
(#40958095)
>which make using multiple processes seem easy are full of footguns which cause deadlocks due to fork-safe code not being well understood. I’ve seen this lead to code ‘working’ and being merged but then triggering sporadic deadlocks in production after a few weeks
Compared to theads being "pain free"?
The default for multiprocessing is still to fork (fortunately changing in 3.14), which means all of your parent process’ threaded code (incl. third party libraries) has to be fork-safe. There’s no static analysis checks for this.
This kind of easy to use but incredibly hard to use safely library has made python for long running production services incredibly painful in my experience.
[1] Some arguments to subprocess.popen look handy but actually cause python interpreter code to be executed after the fork and before the execve, which has caused production logging-related deadlocks for me. The original author was very bright but didn’t notice the footgun.