Indeed it seems that someone, some when, failed to release the lock.
At the time of the deadlock the third thread (The ReceiverThread) is
dispatching on a different eventbase.
This third thread does do some manipulation on bufferevents that are registered
with the Sender's event_base:
void CBTcpProxy::ClosePXCN(BS_PXCN& pxcn, SIDE closing_peer) const
{
...
struct bufferevent* passive_peer_be = (closing_peer == SIDE_CLIENT ?
pxcn._write_server : pxcn._write_client);
struct evbuffer* passive_out = bufferevent_get_output(passive_peer_be);
bool delete_now = false;
evbuffer_lock(passive_out);
{
if(evbuffer_get_length(passive_out) > 0)
{
bufferevent_setcb(passive_peer_be, NULL, &closing_cb,
&event_cb, (void*)(&pxcn));
}
else
{
bufferevent_disable(passive_peer_be, EV_READ|EV_WRITE);
delete_now = true;
}
}
evbuffer_unlock(passive_out);
if(delete_now)
{
delete &pxcn; //destructor calls bufferevent_free.
}
}
void closing_cb(struct bufferevent *bev, void *ctx)//will be called by the
SenserThread when the output buffer is empty
{
PBS_PXCN p_pxcn = (PBS_PXCN)ctx;
delete p_pxcn;
}
This is the only interaction with the third thread.
I do not see a relation to the deadlock.
Thanks,
Avi
-----Original Message-----
From: owner-libevent-us...@freehaven.net
[mailto:owner-libevent-us...@freehaven.net] On Behalf Of Nick Mathewson
Sent: Friday, July 02, 2010 8:48 PM
To: libevent-us...@freehaven.net
Subject: Re: [Libevent-users] deadlock in libevent-2.0.5-beta
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.
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
