On Wed, Aug 8, 2012 at 11:43 PM, Dave Hart <daveh...@gmail.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
