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)
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 On Thu, May 2, 2013 at 2:12 AM, Nick Mathewson <[email protected]> wrote: > On Wed, May 1, 2013 at 12:07 PM, Sashan Govender <[email protected]> > wrote: > > Hi > > > > I need to clarify my understanding of how bufferevent objects work with > > mulithreaded code. If a bufferevent triggers a callback (read or write) > does > > it hold a lock until that callback completes? > > Ordinarily, yes. You can override this with the > BEV_OPT_UNLOCK_CALLBACKS option, as described in > http://www.wangafu.net/~nickm/libevent-book/Ref6_bufferevent.html > > > Do the locks use a recursive > > mutex? > > Yes. > > Yrs, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
