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.