Koushik Chakravarty writes ("[tools/libxl]: Possible bug in ao_cancel"):
> I spotted a possible bug in ao_cancel (libxl_event.c) and wanted to run it
> through you.
Hi, sure. (Sorry for the delay replying, I have been away. And I'm
going away again for the whole of next week...)
> In the ao_cancel(), we mark the parent->cancelling = 1 so that subsequence
> cancel calls don't get entertained and mess things up. However, in my view,
> setting this should be after we check for "parent->cancellables".
>
> This is because, if someones invokes libxl_ao_cancel(), while there are no
> cancellables registered, then further calls to libxl_ao_cancel() should not
> be rejected - as the first call actually didn't do anything.
> I hope I am making myself clear.
Yes, your question is clear, thanks. I don't think you're right,
though.
After cancelling is set, libxl__ao_cancellable_register rejects any
further attempts to set up any cancellables. So I think the situation
you describe (where the libxl_ao_cancel would do nothing but return
CANCELLED because cancelling was already set, but in fact there is a
cancellable which could be notified) cannot arise.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
