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. -- Nick *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
