From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHbfi-0006CO-D5 for qemu-devel@nongnu.org; Mon, 18 Mar 2013 11:08:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHbfd-00085j-AB for qemu-devel@nongnu.org; Mon, 18 Mar 2013 11:08:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHbfd-00085W-1d for qemu-devel@nongnu.org; Mon, 18 Mar 2013 11:08:17 -0400 Message-ID: <51472DD2.20202@redhat.com> Date: Mon, 18 Mar 2013 16:08:02 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <50e744fbae4b08dc4ec33d5d44acc83da7170391.1363264726.git.mst@redhat.com> <87zjy0946n.fsf@codemonkey.ws> <20130318143551.GA13513@redhat.com> In-Reply-To: <20130318143551.GA13513@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 2/3] qom: pass original path to unparent method List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Anthony Liguori , Eduardo Habkost , libvir-list@redhat.com, Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, Gerd Hoffmann , Luiz Capitulino , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Il 18/03/2013 15:35, Michael S. Tsirkin ha scritto: > > There's no harm AFAICT in doing this and it seems more logical to me to > > have destruction flow start with the subclass and move up to the base > > class. > > At Paolo's request children are intentionally reported before parents, > shouldn't this apply? That's ok. Because children are reported first, the parent's path will still be in place while the children are being unparented. Subclasses and the composition tree form two different dimensions, but in both cases the idea is to unparent bottom-up: 1) subclasses dictate the order in which to unparent a single object. The subclasses should be "disconnected" first, before moving up towards Object whose unparenting is done by object_parent_del_child. This way, when a subclass's unparent runs the superclass's bits are still in a good state. 2) the composition tree dictates the order in which to unparent multiple objects. Here children should be unparented first. This way, when a child's unparent runs the parent is still in a good state. Paolo