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

[Arun R Bharadwaj <arun@linux.vnet.ibm.com>]

* 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.

-arun