On 01/02/2013 1:44am, Guido van Rossum wrote:

I'm guessing those system calls are just implemented by the kernel and cannot block for I/O, so it was deemed unnecessary to release the GIL around them. I don't mind changing that though, you can never know what happens when you make a system call.

close() can block, so I assume the same is true of dup2(), since dup2(oldfd, newfd) closes oldfd. -- Richard

...

dup2(oldfd, newfd) closes oldfd.

No, it doesn't close oldfd.

It may close newfd if it was already open.

(I guess that's what he meant). Anyway, only dup2() should probably release the GIL. One reasonable heuristic is to check the man page: if the syscall can return EINTR, then the GIL should be released.

Le Fri, 1 Feb 2013 15:18:39 +0100, "Amaury Forgeot d'Arc" a écrit :

2013/2/1 Charles-François Natali

...

...

...

dup2(oldfd, newfd) closes oldfd.

No, it doesn't close oldfd.

It may close newfd if it was already open.

(I guess that's what he meant).

Anyway, only dup2() should probably release the GIL.

One reasonable heuristic is to check the man page: if the syscall can return EINTR, then the GIL should be released.

Should the call be retried in the EINTR case? (After a PyErr_CheckSignals)

I don't think we want to retry low-level system calls (but I'm not sure we're currently consistent in that regard). Regards Antoine.

On Fri, 1 Feb 2013 15:25:27 -0800 "Gregory P. Smith" wrote:

On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou wrote:

...

Le Fri, 1 Feb 2013 15:18:39 +0100, "Amaury Forgeot d'Arc" a écrit :

...

2013/2/1 Charles-François Natali

...

...

...

dup2(oldfd, newfd) closes oldfd.

No, it doesn't close oldfd.

It may close newfd if it was already open.

(I guess that's what he meant).

Anyway, only dup2() should probably release the GIL.

One reasonable heuristic is to check the man page: if the syscall can return EINTR, then the GIL should be released.

Should the call be retried in the EINTR case? (After a PyErr_CheckSignals)

I don't think we want to retry low-level system calls (but I'm not sure we're currently consistent in that regard).

I think this is what you meant but to be clear: Anywhere we're using them within a library for a good purpose, we do need to retry. If we're merely exposing them via the os module such as os.dup, its up to the caller to deal with the retry.

Indeed, that's what I meant. Sorry for not being very clear. Regards Antoine.

Charles-François Natali wrote:

Anyway, only dup2() should probably release the GIL.

Depending on how your kernel is implemented, both pipe() and socketpair() could create file system entries, and therefore could block, although probably only for a very short time. -- Greg