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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
