Following my first question, I think I found a deadlock bug.
During the program shutdown, I call from a thread different from base event
thread.
bufferevent_setcb(bev, NULL, NULL, NULL, NULL);
bufferevent_disable(bev, EV_READ|EV_WRITE);
Sometimes the call to bufferevent_disable deadlocks at the following line
at event.c:2220:
if (base->current_event == ev && !EVBASE_IN_THREAD(base)) {
++base->current_event_waiters;
EVTHREAD_COND_WAIT(base->current_event_cond, base->th_base_lock);
}
The other thread that is holding the lock is in bufferevent_readcb()
function at bufferevent_sock.c:133
_bufferevent_incref_and_lock(bufev);
it's deadlocked because the first thread is already holding the lock of bev
at line bufferevent.c:502 (in function bufferevent_disable).
Cheers,
On Fri, Jun 21, 2013 at 9:23 PM, Roman Gershman <[email protected]> wrote:
> Hi,
>
> I am trying to understand the invariants the libevent library provides
> when we free its resources.
>
> Specifically, if I call bufferevent_free(my_bev) in a thread different
> from the main event_loop thread, is it guaranteed that my_bev's callbacks
> will never run after bufferevent_free call completes?
>
> Moreover, if the callbacks were running during the call to
> bufferevent_free(), is it guaranteed that they finished to run as well?
> Does BEV_OPT_UNLOCK_CALLBACKS affect this behavior?
>
> Note that I do not use BEV_OPT_DEFER_CALLBACKS flag.
>
> I am using 2.0.19-stable version of libevent library.
>
>
> Thanks!
>
