<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Feb 17, 2010 at 11:59 AM, Dave Angel <span dir="ltr"><<a href="mailto:davea@ieee.org">davea@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Terry Reedy wrote:<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="moz-text-flowed" style="font-family: -moz-fixed">On 2/16/2010 4:37 PM, Doron Tal wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is the GIL released during import statement execution when accessing the<br>
file?<br>
If not, is it a bug?<br>
If it is not a bug, or it is here to stay for any other reason, I think<br>
it should be mentioned in the documentation.<br>
</blockquote>
<br>
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.<br>

<br>
tjr<br>
<br>
</blockquote></div></div>
Threading vs. imports is mentioned at least once in the Python docs.  See   <a href="http://docs.python.org/library/threading.html" target="_blank">http://docs.python.org/library/threading.html</a>, section 17.2.9 (at least in version 2.6.4)<br>

<br>
"""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:<br>
<br>
   * Firstly, other than in the main module, an import should not have<br>
     the side effect of spawning a new thread and then waiting for that<br>
     thread in any way. Failing to abide by this restriction can lead<br>
     to a deadlock if the spawned thread directly or indirectly<br>
     attempts to import a module.<br>
   * Secondly, all import attempts must be completed before the<br>
     interpreter starts shutting itself down. This can be most easily<br>
     achieved by only performing imports from non-daemon threads<br>
     created through the threading module. Daemon threads and threads<br>
     created directly with the thread module will require some other<br>
     form of synchronization to ensure they do not attempt imports<br>
     after system shutdown has commenced. Failure to abide by this<br>
     restriction will lead to intermittent exceptions and crashes<br>
     during interpreter shutdown (as the late imports attempt to access<br>
     machinery which is no longer in a valid state).<br>
<br>
"""<br>
<br>
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<br>
 if __name__ == "__main__":<br>
<br>
portion.  If we're inside that portion, we're not a module, we're a script.<br>
<br>
Even better, import all your modules before starting any new threads.<br>
<br>
DaveA<div><div></div><div class="h5"><br>
<br>
<br>
-- <br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br>No argue here.<br>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.<br>
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).<br><br>--doron<br></div>