Nick Coghlan <ncogh...@gmail.com> added the comment: 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. ---------- assignee: barry -> priority: release blocker -> normal _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9573> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
