On Wed, May 15, 2013 at 3:37 PM, Nick Mathewson <[email protected]> wrote:
> On Wed, May 15, 2013 at 6:24 AM, Sashan Govender <[email protected]> > wrote: > > So in theory the following scenarios should not deadlock: > > > > This all happens in a single thread: > > 1) a bufferevent read callback is triggered (lock acquired) > > 2) the user supplied callback function reads the data and calls > > bufferevent_write (lock acquired - ok because using a recursive mutex) > > Right. > > > and neither should this where 2 threads are involved: > > 1) a bufferevent read callback is triggered > > 2) the user supplied callback function does some stuff (callback ends -> > > lock released by libevent) > > 3) bufferevent_write is called from another thread > > Right, so long as there isn't some kind of a deadlock scenario where > the two threads are acquiring locks in different order. > > If you *are* hitting a mysterious bufferevent-related deadlock, though > ,you might want to check out Libevent 2.1.3-alpha: it has a fix for a > longstanding tricky deadlock in bufferevents related to how > event_del() handles an event that is currently running its callback. > Thanks. I'll give 2.1.3-alpha a go. I'll also try and strip away more of my code till I have a reproducible case for libevent or I find the problem in my code. I've tried enabling the multithreaded debugging (evthread_enable_lock_debugging) but that doesn't trigger any assertions.
