[Python-Dev] epoll implementation

["Martin v. Löwis"]

Ross Cohen wrote:
> I've never been fond of the edge-triggered mode. It's a pretty minor
> optimization, it saves scanning the set of previously returned fds to see
> if the events on them are still relevant. Given that there are added
> pitfalls to using that mode, it never seemed worth it. Any layer in python
> which tries to smooth over the differences will certainly kill the benefits.

I thought about this (even though I never used it), and I think there
are good uses for EPOLLET. Suppose you have a large set of descriptors
where you possibly want to write to.

So you poll for write, then write, then poll again. Eventually you fill
the write buffer, and need to wait for the other side to read some data;
you block in poll. Later, you have sent all data you wanted to send,
yet the connection remains open. So you have to *remove* the fd from
the poll list, because otherwise poll would return immediately each
time. So you keep adding and removing file descriptors to the epoll
set, essentially for each write operation.

I imagine it would be more efficient to just leave the write file
descriptors in the set, even if you have sent all data. With EPOLLET,
the epoll_wait will just ignore those descriptors, and it will watch
only those for which you have actually filled the transmit queue,
and where you have pending data.

This feature sounds reasonable to me.

> Ok, I'm not familiar with intimate details of kqueue. However, if there
> were a select.poll implementation based on kqueue, it would still be an
> improvement, since there isn't *any* implementation on OS X right now.

That depends on the kernel version, no? I though 10.4 added poll.

Also, kqueue support would be for the BSDs primarily. If somebody
contributed a patch, I would accept it providing it was disabled on
OSX (assuming kqueue really is not true poll replacement on this
system).

Regards,
Martin