poll vs. epoll

[Dan Kegel]

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