Author neologix
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall
Date 2013-01-06.00:28:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0FCkimzeZoisg_VqeWcY3g7z1Bgrjk0FacdPfExhoiZg@mail.gmail.com>
In-reply-to <1357419959.63.0.781348542312.issue16853@psf.upfronthosting.co.za>
Content
I've noticed a bug present in Tulip, pyftpdlib and tornado (and this
implementation, too): none of them passes the maxevents argument to
epoll.poll(), and by default the poll() wrapper in the socket module
uses FD_SETSIZE-1, so you'll never get more than FD_SETSIZE-1 events.

Note that the default value used by epoll() is probably too low (we
could maybe use an heuristic to use RLIMIT_NOFILE hard limit, with
capping because it can be quite large on FreeBSD or the Hurd ;-), or
at least the documentation doesn't warn users enough about this. The
signature reads:
"""
.. method:: epoll.poll(timeout=-1, maxevents=-1)

   Wait for events. timeout in seconds (float)
"""

Which confuses users into thinking that the number of returned events
is unlimited by default.

> The EpollSelector and PollSelector implementations are basically identical.  You might want to refactor these to share more code.

Yes, but I find the current code much easier to read: epoll() and
poll() have different constants, different units for timeout, epoll()
must accept a maxevents argument, have a close() method, etc.
History
Date User Action Args
2013-01-06 00:28:54neologixsetrecipients: + neologix, gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, rosslagerwall, felipecruz
2013-01-06 00:28:54neologixlinkissue16853 messages
2013-01-06 00:28:54neologixcreate