On Sun, Jul 4, 2010 at 6:43 AM, Nick Mathewson <ni...@freehaven.net> wrote: > On Sat, Jul 3, 2010 at 2:10 AM, Zhou Li <echou...@gmail.com> wrote: >> I met such deadlock too. It happened under very high load just as you said. >> I think the cause is that the call write(th_notify_fd[1]) got blocked ( >> sorry I didn't remember the exact position of this call to write >> th_notify_fd). >> In event.c line 2597: >> /* >> This can't be right, can it? We want writes to this socket to >> just succeed. >> evutil_make_socket_nonblocking(base->th_notify_fd[1]); >> */ >> When I uncommented this block of code, the deadlock disappeared. >> > > This change isn't correct, though. th_notify_fd[1] is used to tell > the main thread (the one running event_base_loop) to wake up. The > code that writes to it doesn't check for EAGAIN, so making that > socket nonblocking means that some attempts to wake up the main thread > will just get lost.
I don't have the code in front of me now, but I suspect that's fine. If write() on a pipe returns EAGAIN, it has PIPE_BUF bytes already in it. That means that there's already a wake-up queued. Unless the main thread does as little as possible on each wake-up (which would seem odd), that's all you need. A return of -1/EAGAIN is just as good as a return of 0 in this case. > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. > -- Scott Lamb <http://www.slamb.org/> *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
