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
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
