[Python-Dev] epoll implementation

"Martin v. Löwis" martin at v.loewis.de
Fri May 26 20:48:42 CEST 2006


Ross Cohen wrote:
> I agree that it should go into the select module, but not as a seperate
> set of calls. epoll is strictly better than poll. kqueue is strictly
> better than poll. Windows has its own completion ports API. Why should
> an application developer have to detect what platform they are running on?

Because the APIs have different semantics. Design some API for epoll,
and make it replace select or poll (your choice), and I create you
an application that breaks under your poll "emulation".

If a complete emulation was possible, the OS developers would not have
invented a new API.

> Why not simply provide the best implementation for the platform through the
> python API everyone is already using?

Well, what *is* the API everyone is already using? This is really
something for a higher-level API that assumes a certain processing
model (unless the OS API, which assumes no processing model).

Python has a tradition of exposing system APIs *as is*, with no
second-guessing either the OS developers, nor the application
developers. Then, we put a unified API *on top* of that. For
event processing, the standard library always provided
asyncore/asynchat, although people don't like it. I'm sure
the Twisted people would integrate epoll in no time, and with
no API change for *their* users.

Regards,
Martin


More information about the Python-Dev mailing list