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 neologix
Recipients bobbyi, gregory.p.smith, neologix, pitrou, vstinner
Date 2011-05-05.05:41:46
SpamBayes Score 5.719935e-09
Marked as misclassified No
Message-id <BANLkTinHvA-re2T-d==BmVp+_E-0t8D0Pw@mail.gmail.com>
In-reply-to <BANLkTi=WW6=Xqv_=JjiFA8UyWVdLKwsoKw@mail.gmail.com>
Content
Please disregard my comment on PyEval_ReInitThreads and _after_fork:
it will of course still be necessary, because it does much more than
just reinitializing locks (e.g. stop threads).
Also, note that both approaches don't handle synchronization
primitives other  than bare Lock and RLock. For example, Condition and
Event used in the threading module wouldn't be reset automatically:
that's maybe something that could be handled by Gregory's atfork
mechanism.
History
Date User Action Args
2011-05-05 05:41:46neologixsetrecipients: + neologix, gregory.p.smith, pitrou, vstinner, bobbyi
2011-05-05 05:41:46neologixlinkissue6721 messages
2011-05-05 05:41:46neologixcreate