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.
--
error compiling committee.c: too many arguments to function
