Hi John, Your point is well taken. Actually, there is a general mis-conception that putting EPOLLET automatically makes the code faster. That is actually not true. The only reason you benefit from EPOLLET, is because if you do miss reading the entire data from the sock buffer, you dont constantly get pinged about something to read.
Theoretically, if your system is implemented correctly, as in read all the data available from the network buffer (till you hit EAGAIN, or better yet less than the amount you've asked to read), you really dont need to use EPOLLET. There is a plan on removing EPOLLET from the system. One can achieve the same system usage time, with and without EPOLLET. -Anirban On Nov 14, 2009, at 1:57 PM, John Plevyak wrote: > > A couple things: > > 1. Current epoll seems to use EPOLLET in most cases (except for example the > initial DNS connection). > Is this required? It wasn't the case before and it isn't portable. Was it > put in for performance? > libev doesn't support EPOLLET because it isn't portable, and this requirement > would prohibit an > OSX port. > > 2. libevent is currently between the stable 1.X and a new 2.X-alpha with a > new API. It doesn't seem sensible > to either use the old API which is going away or use alpha code. > > I thinking of wrapping the current epoll calls and data structures with an > API and try to make it as compatible > as possible with libev and the new libevent 2.0 API. > > If I can get it in decent shape I'll circulate a patch. > > john >
