[Python-Dev] Release or not release the GIL (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sat Feb 2 00:47:25 CET 2013

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🔞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 PyErrCheckSignals) > > 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.

More information about the Python-Dev mailing list