Davide Libenzi wrote:
>Typical
>applications that uses multiplex interfaces uses only one task (
>eventually for each CPU ) that handles many connections.
>
As I mentioned before, this only works if you have the luxury of being
able to write your application and its supporting libraries from
scratch. If you don't have that luxury, you need additional threads in
order to isolate the latency caused by blocking operations.
>Yes, you have
>a lock to be acquired but this is a price you have to pay as soon as you
>choose threads.
>
>
You have to pay for the lock needed to receive the events. What I am
objecting to is having to pay again for a second lock (and condition
variable) to redistribute those events from the thread they were
received on to the thread they will be processed on. An interface that
supports multithreading well will permit events to be delivered directly
to the threads that need to process them.
io_getevents() is an example of an interface that support multithreaded
callers well. Since the divvying up is done in the kernel, the
information exists for its implementation to be later refined to be more
intelligent about when to deliver which events to which threads. For
example, the interface can later implement CPU affinity of events and
concurrency control.
-
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 : Wed Oct 23 2002 - 22:00:29 EST