On Wed, Feb 17, 2010 at 11:59 AM, Dave Angel <da...@ieee.org> wrote: > Terry Reedy wrote: > > <div class="moz-text-flowed" style="font-family: -moz-fixed">On 2/16/2010 >> 4:37 PM, Doron Tal wrote: >> >>> Is the GIL released during import statement execution when accessing the >>> file? >>> If not, is it a bug? >>> If it is not a bug, or it is here to stay for any other reason, I think >>> it should be mentioned in the documentation. >>> >> >> The CPython GIL is a CPython implementation artifact and should not be >> mentioned in the language docs (and is not, as far as I know). Were you >> thinking of something else? And why this specific feature of its behavior, >> whatever it is. >> >> tjr >> >> Threading vs. imports is mentioned at least once in the Python docs. See > http://docs.python.org/library/threading.html, section 17.2.9 (at least > in version 2.6.4) > > """While the import machinery is thread safe, there are two key > restrictions on threaded imports due to inherent limitations in the way that > thread safety is provided: > > * Firstly, other than in the main module, an import should not have > the side effect of spawning a new thread and then waiting for that > thread in any way. Failing to abide by this restriction can lead > to a deadlock if the spawned thread directly or indirectly > attempts to import a module. > * Secondly, all import attempts must be completed before the > interpreter starts shutting itself down. This can be most easily > achieved by only performing imports from non-daemon threads > created through the threading module. Daemon threads and threads > created directly with the thread module will require some other > form of synchronization to ensure they do not attempt imports > after system shutdown has commenced. Failure to abide by this > restriction will lead to intermittent exceptions and crashes > during interpreter shutdown (as the late imports attempt to access > machinery which is no longer in a valid state). > > """ > > So it may or may not use the GIL, but there are thread restrictions during > an import. The rule I try to follow is not to do anything non-trivial > during top-level code of a module, except inside the > if __name__ == "__main__": > > portion. If we're inside that portion, we're not a module, we're a script. > > Even better, import all your modules before starting any new threads. > > DaveA > > > > -- > http://mail.python.org/mailman/listinfo/python-list >
No argue here. The specific problem, as I wrote in reply to Terry, is with the execfile statement. It might be a part of some online plugin machinery. In such case the nature of the cause does not allow to execute it upfront. I think that the problem can be circumvented by first reading the file followed by compile and eval, as being done in Python3 (no execfile there). --doron
-- http://mail.python.org/mailman/listinfo/python-list