> For this patch, I don't see the benefit of putting it in the select
> module, instead of a separate module. Is there a specific reason?

There is at least one, but probably several other modules named "epoll"
or "_epoll" in the wild. These modules implement an epoll interface with
Pyrex, ctypes or C. All of them have a slightly different API. I don't
want to break 3rd party software.

The select module already contains an interface to select and poll. IMO
it's the best place.

> Looking at the code, I don't have many remarks. pyepoll_new may leak
> if epoll_create fails. I think that allowing threading around
> epoll_ctl is useless, but I may be wrong.

Thanks, I've fixed the problem in pyepoll_new.

The Linux kernel protects every call to epoll_ctl with a mutex. It
*could* block and therefor I'm allowing threads around the epoll_ctl() call.