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

[Adrian Chadd <adrian@xxxxxxxxxxxxxxx>]

On 8 August 2012 15:30, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

> Specifically, let me follow up with what I need: I need people with
> good programming taste to read and understand that message, and let me
> know whether you've got any good ideas for fixing it, or whether you
> think my ideas are reasonable.  Any of my ideas would require some
> tricky changes to the guarantees that event_del() provides for
> multithreaded applications; I'm not sure there's one that doesn't.
>
> I am not going to be able to think as well as I would like about this
> bug this without some help... and if I am doing this on my own, I will
> deliver a solution that will not be as good as it could have been. So:
> anybody with a good taste in multithreading and API design able to
> comment?

Personally, I'm of the opinion that it shouldn't be libevent that does
this - that the application should be responsible for ensuring that
event create/delete/modify occurs in the same thread as the base.
Unfortunately that's not the kind of network application environment
people want .. and this is why locking gets hard.

So what's the lock? You have a lock being held in thread A, and the
same lock w/ conditional in thread B, and there's your deadlock? I'm
just staring at this code now to see what you've done.

All of that "EVBASE_IN_THREAD()" checks for doing locking and waiting
is unfortunately very hairy. Is there any reason you haven't just used
a dead list? (ie, mark the event as dead, put event on the dead list,
have it reaped by the owning thread event loop.)



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