This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] libxenlight: fix multiple xenstore watches probl

To: Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxenlight: fix multiple xenstore watches problem
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Thu, 3 Dec 2009 17:08:31 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Vincent Hanquez <Vincent.Hanquez@xxxxxxxxxxxxx>
Delivery-date: Thu, 03 Dec 2009 09:00:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0912031537160.27629@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.0912021455450.26846@kaball-desktop> <20091203154117.GB16654@xxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.0912031537160.27629@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Dec 03, 2009 at 03:39:57PM +0000, Stefano Stabellini wrote:
> You are right about that, but Andres found the bug and fixed it with his
> "clone context to avoid GC corruption" patch.

that's not about whether or not it can works. I think it's just confusing to
clone and share a context in a mono thread where the only thing you want out of
it, is a xenstore handle. You can simply clone a new xs handle, and worst case
scenario, you can extends the xl context to store 2 xs connections.

In the end, the approch is overkill, and complex solution often lead to
unforseen bug (at this was the case here)

> We can limit the memory allocated for the new alloc_ptrs to something
> much smaller than 256 in libxl_clone_context if you are worried about
> memory allocation.

definitely not worried about that.  libxenlight is not a library where
performance matters. (not that i'm saying it will be slow either)


Xen-devel mailing list