On Thu, Oct 14, 2010 at 5:16 PM, Avi Kivity <a...@redhat.com> wrote: > On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote: >> >> I forgot to add that the semantics of cancellation make it difficult >> to write correct user code. Every cancellation user needs to add >> extra synchronization after the cancel call to handle the case where >> the work is currently executing. >> >> This seems tricky to me and I suspect code using this interface will >> be buggy. How about the following? >> 1. Add a return value indicating that the work is currently executing >> (this still requires the caller to add extra synchronization but is at >> least explicit) versus work is no longer on the list. >> 2. Add a flag to block until the work has been cancelled or completed. >> This is useful to callers who are allowed to block. > > Blocking is somewhat against the spirit of the thing, no? While I agree > that the current cancel API is hard to use correctly, blocking defeats the > purpose of the API.
Yes, that's why it would have to be an optional flag or a separate function. The idea is that callers who are able to block on cancellation can use common code instead of implementing it from scratch each time. Stefan