Dennis Lee Bieber <wlfr...@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 -- https://mail.python.org/mailman/listinfo/python-list
