On 10/18/2010 12:47 PM, Arun R Bharadwaj wrote:
* 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.
I agree it's best not to implement c_t_s() now. Using it implies a
stall so we should discourage it.
--
error compiling committee.c: too many arguments to function
