* Avi Kivity <a...@redhat.com> [2010-10-17 10:57:23]: > 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 > >
I would suggest that we have 2 APIs - cancel_threadletwork (current cancel implementation) and cancel_threadletwork_sync (waits for work to complete). As of now there is no known user for cancel_threadletwork_sync. So we can keep this as a TODO for later. I can provide the APIs for both these so that when we have a user for cancel_threadletwork_sync, we can go ahead and implement it. -arun
