[Python-Dev] epoll() and kqueue wrapper for the select module
Gregory P. Smith
greg at krypto.org
Fri Dec 21 01:18:08 CET 2007
On 12/20/07, Ross Cohen <rcohen at snurgle.org> wrote:
> On Thu, Dec 20, 2007 at 06:08:47PM +0100, Christian Heimes wrote:
> > I've written wrappers for both mechanisms. Both wrappers are inspired
> > from Twisted and select.poll()'s API. The interface is more Pythonic
> > than the available wrappers and it reduced the burden on the user. The
> > users don't have to deal with low level control file descriptors and the
> > fd is closed automatically when the object is collected.
> Did you look at the python-epoll module which has been in the Cheese
> Shop for quite some time? There is no messing with a low level control
> file descriptor and it presents an identical interface to select.poll().
> I would claim this whole new interface:
> > epoll interface
> > >>> ep = select.epoll(1)
> > >>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)
> > >>> ep.modify(fd, select.EPOLL_OUT)
> > >>> events = ep.wait(1, 1000)
> > >>> ep.unregister(fd)
> Is a greater burden on the user than:
> >>> import epoll as select
> I would also claim that adding a new interface to accomplish the same
> task is not more pythonic. But I did write the python-epoll module in
> question, so I may be a bit biased.
Providing a compatibility layer that mirrors the select.select or
select.poll interface using the best underlying syscall may be nice but...
In order to gain the most benefit from any of these system calls they should
be exposed directly. Do the compatibility wrapping in python but leave the
low level calls exposed for those that want them, they make a big difference
to what an application can do. (i believe kqueue/kevent can handle signals,
I like this patch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev