GIL state during import
doron.tal.list at gmail.com
Wed Feb 17 12:02:06 CET 2010
On Wed, Feb 17, 2010 at 11:59 AM, Dave Angel <davea at 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
>>> 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.
>> 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.
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list