Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Antoine Pitrou
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. > > > > > >

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Gregory P. Smith
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 w

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Greg Ewing
Amaury Forgeot d'Arc wrote: One reasonable heuristic is to check the man page: if the syscall can return EINTR, then the GIL should be released. Hmmm, curious. According to the MacOSX man pages, both dup() and dup2() can return EINTR, but pipe() and socketpair() can't. I'm particularly

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Greg Ewing
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 _

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Antoine Pitrou
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,

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Amaury Forgeot d'Arc
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 m

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread 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

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Victor Stinner
> dup2(oldfd, newfd) closes oldfd. No, it doesn't close oldfd. It may close newfd if it was already open. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/m

Re: [Python-Dev] Release or not release the GIL

2013-02-01 Thread Richard Oudkerk
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.

Re: [Python-Dev] Release or not release the GIL

2013-01-31 Thread Guido van Rossum
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. On Thu, Jan 31, 2013 at 4:07 PM, Victor Stinner

[Python-Dev] Release or not release the GIL

2013-01-31 Thread Victor Stinner
Hi, While working on the implementation of the PEP 433, I saw different places where Python asks for operating resources without releasing the GIL. In my implementation, I released the GIL in the following places. Is it correct? - os.dup() - os.dup2() - os.pipe() - socket.socketpair() os.listdi