This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
In-reply-to <>
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

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)
    err = select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
    if (err != 0) {
#ifdef EINTR
        if (errno == EINTR) {
            if (PyErr_CheckSignals())
                return -1;
            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.
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