RetroSearch Browse

Sat Feb 2 00:25:27 CET 2013 · https://mail.python.org/pipermail/python-dev/2013-February/123798.html

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130201/ed9de341/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-February/123798.html below:

[Python-Dev] Release or not release the GIL