On Wed, May 15, 2013 at 3:37 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
On Wed, May 15, 2013 at 6:24 AM, Sashan Govender <sashang@xxxxxxxxx> wrote:Right.
> 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, so long as there isn't some kind of a deadlock scenario where
> 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
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.