GIL state during import

[Doron Tal]

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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100217/dff94a6c/attachment-0001.html>