Subject: Re: c-ares re-entrancy patch, 2006-09-30

Re: c-ares re-entrancy patch, 2006-09-30

From: William Ahern <william_at_25thandclement.com>
Date: Tue, 17 Oct 2006 12:41:43 -0700

On Tue, Oct 17, 2006 at 03:39:51PM +0200, Daniel Stenberg wrote:
> On Thu, 12 Oct 2006, William Ahern wrote:
>
> >>I'm a bit reluctant to apply this patch, as I think the implementation is
> >>hairy and I don't see the big win.
> >
> >If you're using your own event loop, I can understand where your coming
> >from. You simply delay calling ares_destroy() until you fall back into the
> >main loop again, where you know for sure there are no extant functions
> >(like ares_process()) with a reference to the channel. But, for instance,
> >if you're using libevent, and particularly if c-ares is sandwiched inside
> >another API, then you can't really provision for that. Delaying something
> >like that is such a headache as to make it a non-starter.
>
> I can agree that allowing the killing of a handle from within a callback
> can be useful.
>
> But still, I don't see how your system pushes this info/fact (that the
> callback killed the handle) back to the caller of ares_process(). How do
> your application know that the callback has killed the handle? What
> prevents it from using the handle again?
>

Oh. How does the *client* application know? It must know, because it
destroyed the handle. It should be keeping track. I.e., if it's using a
state machine it should be in a different state after the handle was closed,
and that state doesn't touch the handle anymore.
Received on 2006-10-17