Message114166
It turns out my proposed patch is incorrect anyway - it will do the wrong thing if a thread *other* than the one doing the fork is in the middle of a nested import at the time the fork occurs.
With issue 7242 establishing that the current thread ID may not survive the forking process on all platforms, the only way I can see to get completely correct semantics for the fork-as-a-side-effect of import case is to give the forking thread another way to detect "did I own the import lock before the fork?". One way to do that would be to move the lock nesting count into thread local storage, although that would likely suffer cross-platform incompatibility fun and games as well.
Given that, I'm inclined to go with what Brett said: don't do that. Use a __name__ == "__main__" guard so the fork only happens when run as a script, not when imported. |
|
Date |
User |
Action |
Args |
2010-08-17 20:56:15 | ncoghlan | set | recipients:
+ ncoghlan, barry, brett.cannon, gregory.p.smith, eric.araujo, r.david.murray, Alex.Roitman |
2010-08-17 20:56:15 | ncoghlan | set | messageid: <1282078575.39.0.152672536072.issue9573@psf.upfronthosting.co.za> |
2010-08-17 20:56:14 | ncoghlan | link | issue9573 messages |
2010-08-17 20:56:13 | ncoghlan | create | |
|