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?
If we want to support killing the handle in the callback, I would favour a
much simpler approach code-wise, that would just mark the handle for deletion
when ares_destroy is called from within a callback, and then check that
marked-to-be-destroyed flag just before ares_process() returns and if set kill
it there for real. I don't like the complicated macros your patch introduces,
as I've had to reread them multiple times just to figure out what they do and
how they work.
-- c-ares -- my preferred DNS asynch resolver libraryReceived on 2006-10-17