From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: [PATCH 0/3] libxl: Permit immediate asynchronous completion Date: Fri, 17 Feb 2012 18:43:56 +0000 Message-ID: <1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com> References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com> <1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com> <20283.43607.571172.475948@mariner.uk.xensource.com> <20286.31877.938411.558236@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ian Jackson writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"): > Yes, you are right, there is a bug in libxl_device_disk_remove / > libxl__initiate_device_remove. I hadn't spotted that the "out" path > from the old device removal code was used in a success case too. > > I will fix it. Please take a look at the following 3-patch series. I have compiled it but not tested it, but I think something like it should work. 1/3 libxl: ao: allow immediate completion 2/3 libxl: fix hang due to libxl__initiate_device_remove 3/3 libxl: Fix eventloop_iteration over-locking Hopefully 1/3 and 2/3 will make the intended behaviour, and the intended usage clear. Sorry for confusing you with a bad example! Thanks, Ian.