Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

[Avi Kivity <avi@redhat.com>]

  On 10/18/2010 12:47 PM, Arun R Bharadwaj wrote:
> * Avi Kivity<avi@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