Prior to this modification the deadlock occurred when the thread that deletes events from the event_base had consumed ~100% CPU (each thread has a dedicated CPU). Now it happens when the thread that adds events to the event_base consumes ~100% CPU.
Avi From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-us...@freehaven.net] On Behalf Of Avi Bab Sent: Sunday, July 04, 2010 1:41 PM To: libevent-us...@freehaven.net Subject: RE: [Libevent-users] deadlock in libevent-2.0.5-beta This made a great improvement - the deadlock still appears but only on even higher loads. Thanks, Avi From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-us...@freehaven.net] On Behalf Of Zhou Li Sent: Saturday, July 03, 2010 9:11 AM To: libevent-us...@freehaven.net Subject: Re: [Libevent-users] deadlock in libevent-2.0.5-beta 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. On Sat, Jul 3, 2010 at 1:48 AM, Nick Mathewson <ni...@freehaven.net<mailto:ni...@freehaven.net>> wrote: On Thu, Jul 1, 2010 at 6:44 AM, Avi Bab <a...@breach.com<mailto:a...@breach.com>> wrote: > > > Running on Linux with pthreads. > > > > One thread (CBTcpProxyListenerThread below) adds bufferevents (with option > BEV_OPT_THREADSAFE) to an event_base. > > A second thread (CBTcpProxySenderThread) dispatches on the event_base. > > > > bufferevents are removed from the event_base either by a third thread or by > the CBTcpProxySenderThread by calling bufferevent_free (without calling > bufferevent_disable first - is this a misuse?). > > > > The deadlock happens on pretty high load: ~6000 bufferevents are added and > removed per second. Each one is triggered for write ~10 times per seconds > (which gives ~60,000 triggeres per-second). The stack traces look like they aren't the whole story. It seems the two threads you listed are both trying to acquire the lock for the event base, and blocking on it.. But what's the stack of the thread that's actually holding the lock? -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net<mailto:majord...@freehaven.net> with unsubscribe libevent-users in the body.
