Author sbt
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, jcea, lesha, neologix, nirai, pitrou, sbt, sdaoden, vinay.sajip, vstinner
Date 2012-05-23.12:49:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1337777348.14.0.157411114282.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
> (1) Good catch. I suspect that this could be mitigated even if we cared 
> about LinuxThreads. I haven't looked, but there's got to be a way to 
> determine if we are a thread or a fork child.

Using a generation count would probably work just as well as the PID: main 
process has generation 0, children have generation 1, grandchildren have 
generation 2, ...

> (2) I think I didn't explain my idea very well. I don't mean that we 
> should release *all* locks on fork. That will end in disaster, as 
> Charles-François amply explained.

So what are you suggesting?  That a lock of the default type should raise
an error if you try to acquire it when it has been acquired in a previous
process?
History
Date User Action Args
2012-05-23 12:49:08sbtsetrecipients: + sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian, lesha
2012-05-23 12:49:08sbtsetmessageid: <1337777348.14.0.157411114282.issue6721@psf.upfronthosting.co.za>
2012-05-23 12:49:07sbtlinkissue6721 messages
2012-05-23 12:49:07sbtcreate