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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:57 EST