qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arun R Bharadwaj
Subject: Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets
Date: Mon, 18 Oct 2010 16:17:42 +0530
User-agent: Mutt/1.5.20 (2009-06-14)

* Avi Kivity <address@hidden> [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 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]