GIL state during import

Doron Tal doron.tal.list at gmail.com
Wed Feb 17 03:44:03 EST 2010


On Wed, Feb 17, 2010 at 1:01 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> 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
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

I'm sorry, I should have explained my case better.
Quoting the documentation (
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
):

 "The lock is also released and reacquired around potentially blocking I/O
operations like reading or writing a file, so that other threads can run
while the thread that requests the I/O is waiting for the I/O operation to
complete."


Since on some cases the IO may be _very_ slow, any IO command which does not
release the GIL can potentially stall the process. There are two problems
(or more...), the first, it may stall the process for unacceptable duration.
The second problem is that it is not an easy task to track down the root
cause of this stall.

In the specific case I'm dealing with, the problematic command is execfile
(at the time of my initial writing I did not know that).

--doron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100217/f1ec5119/attachment-0001.html>


More information about the Python-list mailing list