From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39290 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P7nFz-0000OH-Ri for qemu-devel@nongnu.org; Mon, 18 Oct 2010 06:47:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P7nFx-0003FN-9b for qemu-devel@nongnu.org; Mon, 18 Oct 2010 06:47:55 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:36096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P7nFw-0003Es-Kv for qemu-devel@nongnu.org; Mon, 18 Oct 2010 06:47:53 -0400 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by e28smtp03.in.ibm.com (8.14.4/8.13.1) with ESMTP id o9IAlmkN030023 for ; Mon, 18 Oct 2010 16:17:48 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9IAll533215612 for ; Mon, 18 Oct 2010 16:17:47 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9IAlltR028296 for ; Mon, 18 Oct 2010 16:17:47 +0530 Date: Mon, 18 Oct 2010 16:17:42 +0530 From: Arun R Bharadwaj Subject: Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets Message-ID: <20101018104742.GA3266@linux.vnet.ibm.com> References: <20101013152921.21735.87339.stgit@localhost6.localdomain6> <20101013153110.21735.16669.stgit@localhost6.localdomain6> <4CB72CDC.1010206@redhat.com> <4CB776E3.9030507@linux.vnet.ibm.com> <4CBABA73.6010805@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4CBABA73.6010805@redhat.com> Reply-To: arun@linux.vnet.ibm.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Stefan Hajnoczi , "Venkateswararao Jujjuri (JV)" , qemu-devel@nongnu.org * Avi Kivity [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