Message161405
| 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:08 | sbt | set | recipients: + sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian, lesha |
| 2012-05-23 12:49:08 | sbt | set | messageid: <1337777348.14.0.157411114282.issue6721@psf.upfronthosting.co.za> |
| 2012-05-23 12:49:07 | sbt | link | issue6721 messages |
| 2012-05-23 12:49:07 | sbt | create | |