Use epoll but still lose packet

[Marko Rauhamaa]

Dennis Lee Bieber <wlfraed at ix.netcom.com>:
> (though as I don't really understand the use of this function, that
> may just mean that all the events will be in the one return structure,
> and not that there is only one event).

I use epoll almost every day. You've done a good job explaining it.

> 	Given that your code only has one socket/file-descriptor I have
> to ponder why a simple select() isn't usable; nor do I see anything
> that detects who is sending the packet (there is no .accept() or
> .recv_from() which would provide the remote host information).

The main driver for epoll vs select is that every call to select causes
the kernel to parse the event specification from the arguments, which
can be slow if there are a lot of file descriptors to monitor. With
epoll, the event specification is loaded to the kernel only once.

To get a full benefit from epoll, you call it with the EPOLLET flag. One
nasty problem with epoll's predecessors (select and poll) is that when
output buffers are full, you have to turn on output monitoring
separately, and when the output buffers have room again, you need to
turn output monitoring off. That can create annoying code and silly
traffic between the process and the kernel.

The EPOLLET flag only gives you a notification when the situation
changes. Thus, you would monitor for EPOLLIN|EPOLLOUT|EPOLLET and forget
the file descriptor. epoll_wait will return whenever the input or output
status changes. Really economical. You must be careful, though, if you
forget to react to an event, you won't get another notification before
the status changes again.


Marko