[Python-Dev] epoll implementation (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Fri May 26 20:48:42 CEST 2006
- Previous message: [Python-Dev] epoll implementation
- Next message: [Python-Dev] epoll implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] epoll implementation
- Next message: [Python-Dev] epoll implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]