On Fri, 1 Feb 2013 15:25:27 -0800 "Gregory P. Smith" <g...@krypto.org> wrote: > On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > Le Fri, 1 Feb 2013 15:18:39 +0100, > > "Amaury Forgeot d'Arc" <amaur...@gmail.com> a écrit : > > > 2013/2/1 Charles-François Natali <cf.nat...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
