2013/3/21 Alexander Klauer <alexander.kla...@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
