[Python-Dev] epoll implementation

[Alex Martelli]

On May 26, 2006, at 6:27 PM, Steve Holden wrote:

> Greg Ewing wrote:
>> Fredrik Lundh wrote:
>>
>>
>>> roughly speaking, epoll is kqueue for linux.
>>
>>
>> There are many different select-like things around now
>> (select, poll, epoll, kqueue -- are there others?) and
>> random combinations of them seem to be available on any
>> given platform. This makes writing platform-independent
>> code that needs select-like functionality very awkward.
>>
>> Rather than adding yet another platform-dependent module,
>> I'd like to see a unified Python interface in the stdlib
>> that uses whichever is the best one available.
>>
> Of course that would mean establishing which *was* the best available
> which, as we've seen this week, may not be easy.

I believe it's: kqueue on FreeBSD (for recent-enough versions  
thereof), otherwise epoll where available and nonbuggy, otherwise  
poll ditto, otherwise select -- that's roughly what Twisted uses for  
Reactor implementations, if memory serves me well.  The platform- 
based heuristic should try to identify things this way but let the  
developer easily override if they know better.  (One might add a  
Windows event loop as the best implementation available there --  
Twisted does -- and GUI toolkit based event loops -- but in general  
that takes an abstraction level similar to Twisted's Reactor... maybe  
we should just repurpose that bit of Twisted?-)

I don't think this is feasible for 2.5 (too late in the cycle to add  
major new stuff, IMHO), but it's well worth it for 2.6 (again IMHO).


Alex