Subject: Re: [PATCH 1/4] ares_cancel(): ensure cancellation of all requests

Re: [PATCH 1/4] ares_cancel(): ensure cancellation of all requests

From: Tommie Gannert <tommie_at_spotify.com>
Date: Thu, 21 Mar 2013 13:44:22 +0100

2013/3/21 Alexander Klauer <Alexander.Klauer_at_itwm.fraunhofer.de>:
> How about this:
>
> * Make ares_destroy() more user friendly and allow callbacks to register new
> requests on the channel being destroyed. Those requests would then
> immediately be finished with ARES_EDESTRUCTION.
> * Let ares_cancel() walk through the list, but don't assert it's empty
> afterwards.

+1 on both accounts, but I guess that doesn't fully solve your issue. As a user
of the library, I would think that semantic is sound. Possibly with the addition
that ares_cancel() should not (accidentally) cancel any new requests created
within it, if that could happen.

> Then, to get behaviour (1), one would call ares_cancel(), and for behaviour
> (2), you would use ares_destroy(), followed by ares_init(). A little awkward
> perhaps, but the API would not be broken.
>
> Thoughts?

I'm curious what your use case is, and I agree it's awkward to have to use
ares_destroy() if you don't really mean to destroy it.

*Thinking out loud* Could one perhaps add a channel flag that would alter
the behaviour of ares_cancel()? Basically a boolean disabling the whole
library. Does that make sense? I don't know of any other library doing that,
except for "shutdown," which is what we/you would like to avoid.

-- 
Tommie
Received on 2013-03-21