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 felipecruz, giampaolo.rodola, gvanrossum, neologix, pitrou, rosslagerwall
Date 2013-01-04.13:18:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Here's a new version adressing Guido's comments (except for kqueue, for which I'll add support later when I can test it).

I'm also attaching a benchmark to compare the implementations: as noted by Guido, the complexity of select/poll/epoll are the theoretical ones: in real life, the syscall's cost is probably dwarfed by objects creation, etc.

Here's a run, for two ready FDs among 1018:
$ ./python ~/ -r 2 -m 1018 -t socket 
Trying with 2 ready FDs out of 1018, type socket
<class 'select.EpollSelector'>
<class 'select.PollSelector'>
<class 'select.SelectSelector'>

So this can be interesting when a large number of FDs are monitored.

For sake of cmpleteness, for a sparse allocation (i.e. just a couple FDS allocated near FD_SETSIZE), there's not much gain:
$ ./python ~/ -r 2 -m 1018 -t socket  -s
Trying with 2 FDs starting at 1018, type socket
<class 'select.EpollSelector'>
<class 'select.PollSelector'>
<class 'select.SelectSelector'>

Two points I'm not sure about:
- should EINTR be handled (i.e. retry, with an updated timeout). I'm tempted to say yes, because EINTR is just a pain the user should never be exposed with.
- what should be done with POLLNVAL and POLLERR? Raise an exception (that's what Java does, but since you can get quite quite easily it would be a pain to use), return a generic SELECT_ERR event? FWIW, twisted returns POLLERR|POLLNVAL as a CONNECTION_LOST event.
Date User Action Args
2013-01-04 13:18:11neologixsetrecipients: + neologix, gvanrossum, pitrou, giampaolo.rodola, rosslagerwall, felipecruz
2013-01-04 13:18:11neologixsetmessageid: <>
2013-01-04 13:18:11neologixlinkissue16853 messages
2013-01-04 13:18:11neologixcreate