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 gregory.p.smith
Recipients bobbyi, gregory.p.smith, neologix, pitrou
Date 2011-02-10.17:20:17
SpamBayes Score 7.851233e-06
Marked as misclassified No
Message-id <1297358418.19.0.0185346544457.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
Yeah, I'm trying to figure out what I was thinking then or if I was just plain wrong. :)

I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).

Part of it looks like I wanted a way to detect it was happening as any lock that is held during a fork indicates a _potential_ bug (the lock wasn't registered anywhere to be released before the fork) but not everything needs to care about that.
History
Date User Action Args
2011-02-10 17:20:18gregory.p.smithsetrecipients: + gregory.p.smith, pitrou, bobbyi, neologix
2011-02-10 17:20:18gregory.p.smithsetmessageid: <1297358418.19.0.0185346544457.issue6721@psf.upfronthosting.co.za>
2011-02-10 17:20:17gregory.p.smithlinkissue6721 messages
2011-02-10 17:20:17gregory.p.smithcreate