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.)

Libevent-users mailing list

Reply via email to