poll vs. epoll

[Shachar Shemesh]

Dan Kegel wrote:

> 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?)

We are trying to have as wide support as we can, obviously.

> The one interface rn is missing, I think, is a timer.

Which wineserver needs.

> Buffered events would be a fine addition, too.
> But rn has the basic notification stuff; it was intended to focus on 
> those.

But then why NOT use libevent :-) If you are really itching, why not 
just add edge trigger to libevent?

>> 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.

True, but that does save me on writing and debugging. After all, that's 
why libraries are there for to begin with.

Also, it would seem to me that keeping data in the fd cache until it's 
actually needed saves on copies. Isn't that the case?

>> 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.

For Linux platforms prior to epoll, what's there?

>> 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.

I'm sure it is. So is managing the buffers etc. Thing is - why go into 
it at all if the difference is small?

As an aside I'll mention that I'd like to see those four lines :-)

> What's this about partial memory buffering?  Sounds like you're inventing
> a difficulty here.

It may be that I'm referring to a difficulty that also exists in the 
usual case. I'm talking about half received "packets" of information on 
stream entities (such as TCP sockets and pipes).

> - Dan

       Shachar

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