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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets
Date: Sun, 17 Oct 2010 10:57:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4

 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




reply via email to

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