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