2011/3/3 Antoine Pitrou <report@bugs.python.org>:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
>> Just to be clear, I'm not at all criticizing the current GIL
>> implementation, there's been a great work done on it.
>> I'm just saying that releasing and re-acquiring the GIL around fast
>> syscalls is probaly not a good idea.
>
> If these syscalls aren't likely to yield control to another thread, then
> I agree there's no point in releasing the GIL around them.
> (but is it the case that they are always fast? for example, how about
> dup() on a network file system? or is it indifferent?)

The initial open can take long, but once it's open, calling dup just
implies copying a reference to the open file (a pointer) to the file
descriptor table. No I/O is done (I tested it one a NFS mount).
Now, I don't know Windows at all, but I'm pretty sure that every
operating system does more or less the same thing, and that those
three calls (there might be others) don't block.

>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11382>
> _______________________________________
>