[Python-Dev] epoll implementation

[Ross Cohen]

On Fri, May 26, 2006 at 02:49:44PM -0400, Jean-Paul Calderone wrote:
> On Fri, 26 May 2006 14:31:33 -0400, Ross Cohen <rcohen at snurgle.org> wrote:
> >
> >I agree that it should go into the select module, but not as a seperate
> >set of calls.
> 
> How about "not *only* as a separate set of calls"?  If poll(2) and epoll(4) are both available on the underlying platform, then they should both be exposed to Python as separate APIs.  Then, on top of that, a relatively simple layer which selects the most efficient mechanism can be exposed, and developers can be encouraged to use that instead.

This is reasonable, though it requires some surgery to the select module.
select.poll is a very reasonable layer over whatever mechanism is available.
The system poll call would need to be properly wrapped and exposed in
addition to epoll, because currently it is not.

> Hiding the difference between poll and epoll would be detrimental to more advanced developers since it would hide the edge-triggered mode of epoll, which is still more efficient than the level-triggered mode, since only the level-triggered mode can be considered API-compatible with poll(2) without adding a much more complex layer on top.

I've never been fond of the edge-triggered mode. It's a pretty minor
optimization, it saves scanning the set of previously returned fds to see
if the events on them are still relevant. Given that there are added
pitfalls to using that mode, it never seemed worth it. Any layer in python
which tries to smooth over the differences will certainly kill the benefits.

Of course, that's just my personal preference. If someone wants to use
the edge-triggered mode, by all means let them.

> >epoll is strictly better than poll. kqueue is strictly
> >better than poll.
> 
> AIUI, kqueue actually isn't implemented for PTYs on OS X, whereas poll(2) is.  Given this, I don't think kqueue is actually strictly better.  Although hopefully Apple will get their act together and fix this deficiency.

Ok, I'm not familiar with intimate details of kqueue. However, if there
were a select.poll implementation based on kqueue, it would still be an
improvement, since there isn't *any* implementation on OS X right now.

Ross