Re: [Libevent-users] deadlock in libevent-2.0.5-beta

[Scott Lamb <slamb@xxxxxxxxx>]

On Sun, Jul 4, 2010 at 6:43 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> On Sat, Jul 3, 2010 at 2:10 AM, Zhou Li <echou327@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
>



-- 
Scott Lamb <http://www.slamb.org/>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.