This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author avian
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-06-30.10:05:35
SpamBayes Score 1.33474e-08
Marked as misclassified No
Message-id <>
The way I see it is that Charles-François' patch trades a possibility of a deadlock for a possibility of a child process running with inconsistent states due to forcibly reinitialized locks.

Personally, I would rather have an occasional deadlock than an occasional random crash.

I don't like increasing complexity with fine-grained locking either. While the general case is unsolvable what Giovanni proposed at least solves the specific case where only the basic IO code is involved after a fork. In hindsight the only real life use-case I can find that it would solve is doing an exec() right after a fork().

There are quite a few bugs in the tracker that seem to have this same root cause, so it appears the impossibility of cleanly handling threads and forks is not something people are generally aware of. Since I think we agree you can't just disable fork() when multiple threads are running, how about at least issuing a warning in that case? That would be a two-line change in
Date User Action Args
2011-06-30 10:05:37aviansetrecipients: + avian, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden
2011-06-30 10:05:37aviansetmessageid: <>
2011-06-30 10:05:36avianlinkissue6721 messages
2011-06-30 10:05:35aviancreate