On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote:
> > 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. > Are you proposing to add additional state in the return (canceled/running/not-canceled) and leave the synchronization part to the user? i.e not to provide any additional interface for the user to wait for the scheduled work to finish? Just trying to understand.
I wasn't proposing anything since I don't have a good proposal. Adding a callback makes the whole thing an asynchronous design which threads are trying to avoid. Blocking is bad. Leaving it to the caller is hard to use correctly.
Perhaps we can have a threadlet with barrier semantics. You queue a piece of work which is guaranteed to execute after all previously submitted work (against the same queue) and before any consequently submitted work.
-- error compiling committee.c: too many arguments to function
