Shachar Shemesh wrote:
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.
Don't get me wrong. Libevent is good stuff. Niels is a very good guy.
I don't think platform support is an issue (which platform do you need?)
The one interface rn is missing, I think, is a timer.
Buffered events would be a fine addition, too.
But rn has the basic notification stuff; it was intended to focus on those.
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 essential difference is that level-triggered means more notifications
coming from kernel space, which always means higher overhead. The difference
is going to be slight.
I have also noticed that in some situations where the interest mask
is hard to compute, using edge triggered is much easier, because you
never have to compute it.
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
The same cache is maintained in the kernel for you if you use level triggering.
as well as risking starvation.
There is no risk of starvation in a properly written program.
Also, can you show me how to do edge trigger via poll?
There is no need for that, since Linux and *BSD all support some
form of edge-triggered notification. However, if we want to
support ancient operating systems, it wouldn't be too hard to
add poll() support to rn under the covers, and present the edge-triggered
interface to the user.
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.
Yes, but that's easy. It's about four lines of code.
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.
What's this about partial memory buffering? Sounds like you're inventing
a difficulty here.
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
