Yes, I figured it out by delving into the libevent source code yesterday
I have removed the above stub from the locked code, so now the callback
always completes, and the issue is solved.
Thanks
On Sun, Nov 21, 2010 at 9:58 PM, Nick Mathewson <ni...@freehaven.net> wrote:
> On Sat, Nov 20, 2010 at 6:21 AM, Sherif Fanous <sherif.fan...@gmail.com>
> wrote:
> > Hello
> > I have my event callback receiving data from the network using recv. If
> recv
> > returns 0 (FIN received), I call a function to disconnect and cleanup.
> > Part of my cleanup is as follows
> > if (server->receive_event) {
> > event_free(server->receive_event);
> > server->receive_event = NULL;
> > }
> >
> > I have run into this strange deadlock situation
> > If the cleanup function is called from the event callback then I
> experience
> > no deadlocks.
> > However if the cleanup function is called from another thread, and the
> event
> > callback is executing, then a deadlock occurs. In my case the event
> callback
> > also never terminates as it is waiting on a lock acquired by the cleanup
> > function.
> > Is it normal behavior that event_free won't be able to free the event, if
> > the event is active in another thread?
>
> Right; current behavior is that while an event callback is executing,
> attempts to add, delete, or activate the event from another thread may
> block on a condition variable. Doing an event_free() does an implicit
> event_del().
>
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
>
