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> wrote:
> On Thu, Jul 1, 2010 at 6:44 AM, Avi Bab <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 with
> unsubscribe libevent-users in the body.
>
