From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 01/27] tools/libxl: Fix libxl__ev_child_inuse() check for not-yet-initialised children Date: Tue, 16 Jun 2015 14:36:41 +0100 Message-ID: <55802669.6070209@citrix.com> References: <1434375880-30914-1-git-send-email-andrew.cooper3@citrix.com> <1434375880-30914-2-git-send-email-andrew.cooper3@citrix.com> <1434460912.13744.147.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434460912.13744.147.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Yang Hongyang , Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On 16/06/15 14:21, Ian Campbell wrote: > On Mon, 2015-06-15 at 14:44 +0100, Andrew Cooper wrote: >> Shortly, libxl will be juggling multiple parallel operations, and will >> possibly have to take error decisions before some tasks have been set up. > It would be preferable, I think, to arrange to call libxl__ev_child_init > on all such libxl__ev_child structs either up front or certainly before > there is any possibility of needing to unwind them. > > Such an init would at worst correspond to exactly the place where the > zeroed structure you refer to is zeroed. It is possible that one bit fails before it can be calculated whether the second bit needs to start or not. At the moment, all bits in libxl in this area do initialisation immediately before use; most bits are even initialised in the function which starts their actions. Some bits are initialised differently depending on the path taken to get to the initialisation site. It would be non-trivial to initialise everything appropriately at the very start. ~Andrew