Author neologix
Recipients arigo, giampaolo.rodola, gregory.p.smith, gvanrossum, koobs, neologix, pitrou, sbt, vstinner
Date 2013-12-01.08:14:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2ejADUhf9RiUvrKkUWXhNuYSc7FMiGXBWWFUVm-H=w1w@mail.gmail.com>
In-reply-to <CAGE7PNKmVJk9oZJ-wr4G5z0pu7ihJxAg-51_DoNM00D6GLHKcQ@mail.gmail.com>
Content
Just for the record, I was initially in favor of recomputing the
timeout and retrying upon EINTR, but Guido prefers to return empty
lists, and since that's a better compromise than the current situation
(I've seen *many* people complaining on EINTR popping-up at random
points in the code, including myself), I went ahead and implemented
it.

AFAICT, an early return for calls such as poll()/epoll() etc is
something which is definitely acceptable: if you have a look at e.g.
Tornado, Twisted & Co, they all return empty lists on EINTR.

> I've always had the implicit understanding that if I use an *infinite* timeout then > the call will not timeout.

Well, I've always assumed that time.sleep(n) would sleep n seconds, but:
"""
static int
floatsleep(double secs)
[...]
    Py_BEGIN_ALLOW_THREADS
    err = select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
    Py_END_ALLOW_THREADS
    if (err != 0) {
#ifdef EINTR
        if (errno == EINTR) {
            if (PyErr_CheckSignals())
                return -1;
        }
        else
#endif
        {
            PyErr_SetFromErrno(PyExc_IOError);
            return -1;
        }
    }
[...]
"""

So really, I'm like Gregory: I don't care which solution we chose, but
I just don't want to have to let the user handle EINTR.
History
Date User Action Args
2013-12-01 08:14:58neologixsetrecipients: + neologix, gvanrossum, arigo, gregory.p.smith, pitrou, vstinner, giampaolo.rodola, sbt, koobs
2013-12-01 08:14:58neologixlinkissue18885 messages
2013-12-01 08:14:58neologixcreate