Dan Kegel wrote:
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.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 :-)
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/
