From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34869 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P7oqf-0007sG-Qa for qemu-devel@nongnu.org; Mon, 18 Oct 2010 08:29:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P7oqe-0006hW-P9 for qemu-devel@nongnu.org; Mon, 18 Oct 2010 08:29:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P7oqe-0006h2-Ir for qemu-devel@nongnu.org; Mon, 18 Oct 2010 08:29:52 -0400 Message-ID: <4CBC3DB1.2010400@redhat.com> Date: Mon, 18 Oct 2010 14:29:37 +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> <4CBABA73.6010805@redhat.com> <20101018104742.GA3266@linux.vnet.ibm.com> In-Reply-To: <20101018104742.GA3266@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: arun@linux.vnet.ibm.com Cc: Stefan Hajnoczi , "Venkateswararao Jujjuri (JV)" , qemu-devel@nongnu.org On 10/18/2010 12:47 PM, Arun R Bharadwaj wrote: > * 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. I agree it's best not to implement c_t_s() now. Using it implies a stall so we should discourage it. -- error compiling committee.c: too many arguments to function