[Python-Dev] epoll implementation

[Jean-Paul Calderone]

On Fri, 26 May 2006 14:31:33 -0400, Ross Cohen <rcohen at snurgle.org> wrote:
>On Fri, May 26, 2006 at 08:03:12PM +0200, "Martin v. Löwis" wrote:
>> Ross Cohen wrote:
>> > Is there any interest in incorporating this into the standard python
>> > distribution?
>>
>> I would like to see epoll support in Python, but not in the way PyEpoll
>> is packaged. Instead, I think it should go into the select module,
>> and be named epoll_*.
>>
>> Likewise, if kqueue was ever supported, I think it should also go
>> into the select module.
>
>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.

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.

>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.

>Windows has its own completion ports API. Why should
>an application developer have to detect what platform they are running on?
>Why not simply provide the best implementation for the platform through the
>python API everyone is already using?

So far as this is possible, I think it is a good idea.

Jean-Paul