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 christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt, vstinner
Date 2013-08-30.13:34:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0-Hf9E2zwV8sk50V7dbZ79GxJR39UvJh6qvkj89T6Mdg@mail.gmail.com>
In-reply-to <1377865849.93.0.0483429571021.issue16853@psf.upfronthosting.co.za>
Content
Hello,

> - What about Solaris' /dev/poll?

That should be pretty easy to add by someone who has access to a
Solaris box: I could use the buildbots, but it'd take a couple
iterations to get it right.

> - I'm not sure why in case of EINTR you retry with a different timeout; can't you just return []?

Because when I do:
selector.select(10)

I expect the selector to wait 10 seconds if no event occurs: the fact
that a signal comes in shouldn't break the contract made by the API,
i.e. that it will return when a FD is ready or the timeout expires.
Early return can lead to spurious errors: just imagine you send a
request to a busy server: it would be bad to raise a timeout error
just because the user put the client in the background with CTRL-Z
(which results in SIGSTOP).

> - this is probably because I'm paranoid about performances but given that select() method will be called repeatedly I would not use a decorator. Also, similarly to what has been done elsewhere in the stdlib, for "critical" parts I would recommend localizing variable access in order to minimize overhead as in:
>
>     def select(self, timeout=None):
>         ...
>         key_from_fd = self._key_from_fd
>         ready_append = ready.append
>         for fd in r | w:
>             ...
>             key = key_from_fd(fd)
>             if key:
>                 ready_append((key, events & key.events))

I find that localizing variables leads to unreadable code, and is tied
to the current CPython interpreter implementation: such optimizations
belong to the interpreter, not user code.

As for the decorator performance overhead, I don't think it weights
much compared to the cost of a syscall (+ GIL acquire/release):
with decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
100000 loops, best of 3: 3.69 usec per loop
without decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
100000 loops, best of 3: 3.52 usec per loop

That's a 4% overhead, with a single FD that's always ready (and I
suspect that most of the overhead is due to the call to time(), not
the decorator per se).

Also, I'll shortly propose a patch to handle EINTR within C code, so
those EINTR wrappers won't  be needed anymore.
History
Date User Action Args
2013-08-30 13:34:09neologixsetrecipients: + neologix, gvanrossum, pitrou, vstinner, giampaolo.rodola, christian.heimes, meador.inge, rosslagerwall, sbt, felipecruz
2013-08-30 13:34:09neologixlinkissue16853 messages
2013-08-30 13:34:09neologixcreate