Re: [Libevent-users] Deadlock when calling bufferevent_free from an other thread

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Aug 8, 2012 at 11:43 PM, Dave Hart <davehart@xxxxxxxxx> wrote:
> One solution that comes to mind is to add a (for example)
> event_del_nowait(), or event_del_nonblocking() which requires the
> event in question be allocated dynamically via libevent, and therefore
> can safely use the dead list approach of queuing the deallocation to
> be done by the thread running the event base's loop.  It's ugly to
> require clients to understand the deadlock risk of calling event_del()
> from a thread other than the one servicing the event base loop, but it
> provides the functionality needed for both scenarios.

Hm.  I think that the calling code truly does need to know when the
events are going to be reliably freed, though.

One common use case is that you have some data object that uses one or
more events, and is itself the callback argument for those events.
Let's say that you want to free that object.  You'd better not do so
while the callbacks are running!  So any code that actually frees that
object itself needs to happen after we can know that the events are
truly not running or about to run.  Even if we did a deadlist for
events, I think we'd need a way for objects that those events might be
using to arrange for themselves to be cleaned up only after the events
are certainly dead.

Am I on the right track?

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.