poll vs. epoll
wine-devel at shemesh.biz
Wed Aug 25 00:07:46 CDT 2004
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?
Lingnu Open Source Consulting ltd.
More information about the wine-devel