[Python-Dev] Release or not release the GIL

[Antoine Pitrou]

On Fri, 1 Feb 2013 15:25:27 -0800
"Gregory P. Smith" <greg at krypto.org> wrote:
> On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> > Le Fri, 1 Feb 2013 15:18:39 +0100,
> > "Amaury Forgeot d'Arc" <amauryfa at gmail.com> a écrit :
> > > 2013/2/1 Charles-François Natali <cf.natali at gmail.com>
> > >
> > > > >> 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.