From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: /proc/xen/xenbus supports watch? Date: Thu, 15 Sep 2005 11:39:50 +1000 Message-ID: <1126748390.12119.33.camel@localhost.localdomain> References: <5d7aca9505090801025f3d5771@mail.gmail.com> <3d8eece205090803381b818f18@mail.gmail.com> <1126226609.25110.3.camel@localhost.localdomain> <3d8eece205091302422ac74f77@mail.gmail.com> <1126657264.7896.20.camel@localhost.localdomain> <1126689530.4415.10.camel@localhost.localdomain> <3d8eece205091405555a2871fc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3d8eece205091405555a2871fc@mail.gmail.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: Christian.Limpach@cl.cam.ac.uk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, 2005-09-14 at 13:55 +0100, Christian Limpach wrote: > On 9/14/05, Rusty Russell wrote: > > Patch for reading only (I subbed in NULL for the default store page for > > the moment, since I know there's another patch out there which touches > > this). > > I really don't think that the multi-page approach is good and it's > also orthogonal, i.e. we could have multiple connections but still > want concurrent transactions on the same connection. What's wrong > with concurrent transactions on the same connection? You're right it's orthogonal, but we really do want separate connections for each client: they're logically separate, so overloading them on one transport is going to be a hack. Inside the kernel we do it to a limited degree, but already have a proxy for handling watches and we trust everyone to get it right and use One Big Lock. Now, we still might want concurrent transactions for a single user, but more likely we want to get rid of the "root of transaction" model altogether, since noone likes it, and there's an unrelated issue with NFS-root mounted store (it breaks horribly) that is likely to change our underlying (on-disk directory-based) implementation. Thoughts? Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman