On Wed, Dec 1, 2010 at 5:19 PM, Cameron Simpson <c...@zip.com.au> wrote: > On 01Dec2010 16:49, David Brown <dmlb2...@gmail.com> wrote: > | So I'm not subscribed to python-list but would like to get an answer > | to my question. I've made a small test program that dumps a > | RuntimeError and I'd like to know why. > | > | $ python test2.py > | doing stuff > | Traceback (most recent call last): > | File "test2.py", line 3, in <module> > | import test > | RuntimeError: not holding the import lock > | child 3693 exited with 256 > | $ > | > | Here's the setup, there's two files test.py and test2.py > | > | $ cat test.py > | #!/usr/bin/python > | > | import os, sys > | > | if os.fork() == 0: > | print "doing stuff" > | sys.exit() > | > | print "child %d exited with %d" % os.wait() > | $ cat test2.py > | #!/usr/bin/python > | > | import test > | $ > | > | I understand that sys.exit() is really just doing a `raise > | SystemExit(0)' and the RuntimeError shows up with that as well. If you > | change out sys.exit with os._exit(0) then it doesn't show dump the > | RuntimeError. Also, this seems to be a python2.6 and python2.7 issue. > | Python3 doesn't have this issue. I haven't checked with python2.5 or > | before yet. > | > | I was more curious about what this behavior is and why python is doing > | things this way. I've scoured the python documentation and can't seem > | to figure out why. > > So, test2.py imports "test", which is in "test.py". > And the test module forks _during_ the import. > > Python takes a lock during imports - this stops multiple threads > from importing the same module at the same time (avoiding multiple > instantiation etc) and other racy fribbing with the in-memory module > data structures. > > So: > import test > test.py... > fork... > > At this point two programs exist, each in the midst of the import of > test.py. It would seem the import lock breaks over the fork, so that the > child process doesn't hold the lock. But because it is a fork, it does > not know this! (Being identical to its parent.) So you raise SystemExit, > and during the stack unwind the child tries to release the lock. Which > it doesn't have, thus the breakage. > > Does that clarify the sequence of events?
Thanks for the clarification I like the idea of wrapping all the primary code in the script to a main function then calling it if its being called by main. I think I got a better handle on things. Thanks, - David Brown > Cameron Simpson <c...@zip.com.au> DoD#743 > http://www.cskk.ezoshosting.com/cs/ > > "I think not," said Descartes, and promptly disappeared. > -- http://mail.python.org/mailman/listinfo/python-list
