On 03/21/2013 02:56 PM, Tommie Gannert wrote:
2013/3/21 Alexander Klauer <alexander.kla...@itwm.fraunhofer.de>:
What happens if someone calls ares_cancel() while ares_cancel() is in
progress? With (1), that would mean that the topmost (most recent) instance
ares_cancel() has to cancel all those requests that appeared since the
next-to-topmost instance was invoked, right?
Good corner case.
I try to think of how I would expect it to work if it was just
multiple threads doing
requests and ares_cancel() would cancel them. And I think what you suggest
makes a lot of sense. The second call would be responsible for cancelling all
active requests though, so if you have three requests, A B C, and cancelling A
causes a request D to be created, and then B calls cancel(), then you would
have a request list like "C D" when entering that second cancel(). In that case
both the first and second cancel() would be responsible for cancelling C, and
it would have to be cancelled before the second cancel() returns (and implicitly
thus also the first as they were recursive calls.)
Might be tricky to get right without ref counting. If it requires a lot of code
changes, maybe it's not worth enforcing such strict semantics, though.
Implementation-wise, I think I would just swap the list head in the ares
channel with an empty list head on the stack, and then start walking
through the list with the list head on the stack. Any new requests would
then be added to the now initially empty list in the ares channel.
In your example, the first ares_cancel() would cancel A, B, and C, while
the second ares_cancel() would cancel only D. This approach also works
with more than two ares_cancel()s and no reference counting is needed.
No real use case, my leaning towards (2) is just personal feeling. My actual
use case right now is to call ares_cancel() immediately prior to
ares_destroy(). With the implementation of (1), I would of course simply
call ares_destroy(). I also call ares_cancel() in an out of memory
condition.
Then it sounds like the proposed functionality would actually benefit your code?
It would save one statement, yes.
Best regards,
Alexander
