From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39390 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P7P3c-0006ww-CF for qemu-devel@nongnu.org; Sun, 17 Oct 2010 04:57:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P7P3b-0006St-M9 for qemu-devel@nongnu.org; Sun, 17 Oct 2010 04:57:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P7P3b-0006ST-Fo for qemu-devel@nongnu.org; Sun, 17 Oct 2010 04:57:31 -0400 Message-ID: <4CBABA73.6010805@redhat.com> Date: Sun, 17 Oct 2010 10:57:23 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets References: <20101013152921.21735.87339.stgit@localhost6.localdomain6> <20101013153110.21735.16669.stgit@localhost6.localdomain6> <4CB72CDC.1010206@redhat.com> <4CB776E3.9030507@linux.vnet.ibm.com> In-Reply-To: <4CB776E3.9030507@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Venkateswararao Jujjuri (JV)" Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Arun R Bharadwaj 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