[Libevent-users] sensible thread-safe signal handling proposal

[Steven Grimm]

On Nov 4, 2007, at 3:03 PM, Adrian Chadd wrote:

> On Sun, Nov 04, 2007, Steven Grimm wrote:
>
>> Now if only there were a way to wake just one thread up when input
>> arrives on a descriptor being monitored by multiple threads... But
>> that isn't supported by any of the underlying poll mechanisms as far
>> as I can tell.
>
> Would this be for listen sockets, or for general read/write IO on an  
> FD?

Specifically for a mixed TCP- and UDP-based protocol where any thread  
is equally able to handle an incoming request on the UDP socket, but  
TCP sockets are bound to particular threads.

Unfortunately the vast majority of incoming requests are on the UDP  
socket, too many to handle on one thread.

Before anyone suggests it: a message-passing architecture (one thread  
reads the UDP socket and queues up work for other threads) gave me  
measurably higher request-handling latency than the current setup,  
which works but eats lots of system CPU time because all the threads  
wake up on each UDP packet. It makes sense: the current scheme  
involves fewer context switches for a given request (at least, on the  
thread that ends up handling it), and context switches aren't free.

Ideally I'd love a mode where I could say, "Only trigger one of the  
waiting epoll instances when this descriptor has input available."  
Sort of pthread_cond_signal() semantics, as opposed to the current  
pthread_cond_broadcast() semantics. (Yes, I'm aware that  
pthread_cond_signal() is not *guaranteed* to wake up only one waiting  
thread -- but in practice that's what it does.)

-Steve