From: Ron / BCLUG via talk <talk@gtalug.org>
D. Hugh Redelmeier via talk wrote on 2025-02-08 09:25:
- Python is bone-headed about forks. In a host of ways. I knew that.
This last part I didn't know.
Care to expand upon it - interesting topic in its own right.
Disclaimer: I don't program in Python. The language itself is easy enough to understand but the libraries are a lot (good for functionality but daunting to master). Anyway, it means that I may have some things wrong about Python. Python was designed to do its own version of threads. That design didn't exploit the capabilities of modern computers: multiple cores. There appear to be a variety of hacks to get around this. Too often shared resources don't work, and they don't work in mysterious ways. global python locks are no longer global if you use a UNIX fork. This can manifest in non-deterministic ways. One problem is that these locks are thought to be private, within the implementation of some abstraction, but their misbehaviour in the face of fork is definitely a public problem. See, for example: <https://bugzilla.redhat.com/show_bug.cgi?id=1691434> <https://bugs.python.org/issue35866> It took over two years to close this bug. Discovering race conditions should not be left to test cases. This is a prime example of never being able to prove the absence of bugs through testing. The main answer from the Python people was "don't fork": the library wasn't designed to work with it. Perhaps it is better six years on.