Messages in this thread | | | Date | Tue, 15 Oct 2002 14:50:04 -0700 | From | (John Myers) | Subject | Re: [PATCH] async poll for 2.5 |
| |
Dan Kegel wrote:
>The most effective way to use something like /dev/epoll in a >multithreaded >program might be to have one thread call "get next batch of events", >then divvy up the events across multiple threads. > That is a tautology. As /dev/epoll is inherently a single threaded interface, of course the most effective way for a multithreaded program to use it is to have one thread call it then divvy up the events. That's the *only* way a multithreaded program can deal with a single threaded interface.
The cost to divvy up the events can be substantial, not the mention the cost of funneling them all through a single CPU. This cost can easily be greater than what one saves by combining events. io_getevents() is a great model for divvying events across multiple threads, the poll facility should work with that model.
The solution for optimizing the amount of event collapsing is to implement concurrency control.
>Once you allow that, it's easy to handle the >condition you're worried about by generating a spurious readiness >indication when registering a fd. That's what I do in my wrapper >library. > This is a workaround. You are adding additional code and complexity to the caller in order to deal with a deficiency in the interface. This has several problems:
Someone writing to the /dev/epoll interface needs to know that they need to write such workaround code. If they don't know to write the code or if they make an error in the workaround code, it is still likely that the program will pass testing. What will result are intermittent, hard to diagnose failures in production.
User space does not have the information to address this as well as the kernel can. As a result, the workaround requires more processing in the common, non racy case.
The kernel can clearly handle this situation better than user space. It can do the necessary checks while it is still holding the necessary locks. It is less error prone to handle the situation in the kernel. The logic clearly belongs in the kernel.
>Also, because /dev/epoll and friends are single-shot notifications of >*changes* in readiness, there is little reason to register interest in >this or that event, and change that interest over time; instead, >apps should simply register interest in any event they might ever >be interested in. > You're making assumptions about the structure and flow of an application. Sometimes when an application stops having interest in this or that event, it needs to free/invalidate the context associated with that event.
So that's fine as a strategy for amortizing the cost of registration/deregistration, but it isn't universally applicable.
[unhandled content-type:application/x-pkcs7-signature] | |