poll vs. epoll

[Shachar Shemesh]

Dan Kegel wrote:

> Shachar Shemesh wrote:
>
>> It doesn't compile (rn.c is not including <sys/epoll.h>). When I fix 
>> that, it checks whether epoll_create works. If it does, it sets all 
>> handlers to use sigio. I don't think this library is quite stable 
>> enough :-)
>
>
> You're a tough customer :-)  It's quite close; guess I should polish 
> it up a bit.
>
>> In any case, it seems that it's interface is not ideal for 
>> wineserver. Libevent, on the other hand......
>
>
> Now don't go and do level-triggered stuff just because it's easier :-)
>
That's not it at all, and edge vs. level is not part of my 
considerations. Libevent does support a wider variety of selection 
interfaces, and with wider platform support, than your library.

> I don't think it's fair to say level-triggered is ideal for
> wineserver.  In fact, wineserver is an example of the kind
> of program that is easier to convert to edge-triggering
> than most programs, since it's small and self-contained.

Can you give benchmarks for performance differences between the two? The 
more I think about it, the more I'm getting the impression that going 
edge trigger means we need to maintain our own cache of not-yet-useful 
data, as well as risking starvation. I'm sure there are cases where this 
is preferable, but can you explain why this is such a case?

Also, can you show me how to do edge trigger via poll?

> Sigh.  I wish my wrists were in better shape; I'd convert it
> myself.  As it is, he who does the work gets to choose interfaces.
> - Dan

I'll qualify the starvation claim.

Suppose we have five fds we are watching. Suppose one (let's call it 
"3") of them is really really intensive in it's request rate. Using the 
current interface (as used in the preliminary patch I sent), each time 
we call epoll we will see that 3 is active, but any time any other fd 
has anything to do, it will be handled.

Suppose we go edge triggered now. We call epoll, and it's likely that 3 
will be the only one active. We will call the 3 handling function, which 
will try to exhaust the requests arriving on 3 before returning. No it's 
a problem - requests potentially are never exhausted on 3. When do we 
exit the handler to do other stuff? We would need to write some 
mechanism to introduce this fairness ourselves.

In short, if you are going edge trigger, your relative scheduling 
priority is your responsibility, as well as keeping all partial memory 
buffered. With level trigger, the kernel does that for you. Is there any 
reason to assume that we can do that better than the kernel?

                Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/