From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54909 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6VPW-0002ve-9P for qemu-devel@nongnu.org; Thu, 14 Oct 2010 17:32:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6VPV-0000bI-66 for qemu-devel@nongnu.org; Thu, 14 Oct 2010 17:32:26 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:43189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6VPV-0000b3-3e for qemu-devel@nongnu.org; Thu, 14 Oct 2010 17:32:25 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9ELPDoB027640 for ; Thu, 14 Oct 2010 17:25:13 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9ELWKca475520 for ; Thu, 14 Oct 2010 17:32:20 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9ELWJCZ021314 for ; Thu, 14 Oct 2010 15:32:19 -0600 Message-ID: <4CB776E3.9030507@linux.vnet.ibm.com> Date: Thu, 14 Oct 2010 14:32:19 -0700 From: "Venkateswararao Jujjuri (JV)" 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> In-Reply-To: <4CB72CDC.1010206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Arun R Bharadwaj On 10/14/2010 9:16 AM, Avi Kivity wrote: > On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote: >> I forgot to add that the semantics of cancellation make it difficult >> to write correct user code. Every cancellation user needs to add >> extra synchronization after the cancel call to handle the case where >> the work is currently executing. >> >> This seems tricky to me and I suspect code using this interface will >> be buggy. How about the following? >> 1. Add a return value indicating that the work is currently executing >> (this still requires the caller to add extra synchronization but is at >> least explicit) versus work is no longer on the list. Current semantics is .. if not on the list it is currently executing or we are done with it. How do we differentiate between those two? Do we need any other state? >> 2. Add a flag to block until the work has been cancelled or completed. >> This is useful to callers who are allowed to block. > > 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. Thanks, JV