Re: [Xen-devel] XenStore Watch Behavior

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 29/8/06 3:22 am, "John McCullough" <jmccullo@xxxxxxxxxxx> wrote:

> Recently I discovered that my watch and the xswatch were receiving
> alternating watches (both in python).  Looking at xs_read_watch in
> tools/xenstore/xs.c, the mutex on the xshandle forces all xs_read_watch
> calls to take turns.  Given that the python interface shares a single
> xshandle, this prevents multiple watches.
> 
> Creating an entirely new xshandle for each use of read_watch works.
> Moving to a model where the xsutil.xshandle() call creates a new
> xshandle seems easily supportable, given that xswatch is primarily used,
> and it keeps a reference to it's own handle.
> 
> Does anyone know of other xshandle() uses that warrant the current
> behavior?

The current behaviour is broken (or, at least, the semantics really make no
sense at all) if multiple people create 'xs' objects in the same python
program. A good fix would be to move the handle allocation from
xshandle_init to xshandle_new. The latter function will have to create a new
container object to hold the handle value, rather than returning self.
Watches will then be registered and read in the isolated context of a
particular caller's object handle, rather than a bogus shared global context
of all users of the xs library.

This fix should then get things working for your code if you create yourself
an xs object separate from xswatch's. It only raises the question how you
then implement a central select loop in your python program that waits on
the various file handles or sockets created by the various xs objects.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel