Re: XenStore Watch Behavior

[John McCullough <jmccullo@cs.ucsd.edu>]

Ewan Mellor wrote:
> If you want to have data that outlive the domain (I presume in your case for
> just a short while) then you should put them somewhere other than
> /local/domain.  There is a /tool/<yournamehere> hierarchy reserved for
> third-party tools, if that suits you better.  You would then have to handle
> all the sweep-up yourself of course.
> 
> In your case, couldn't you just release the semaphore off the @releaseDomain
> watch?  Don't forget, domains can spontaneously self-destruct, maybe even
> half-way between your "shutdown" and "shutdown_done", so you need to be able
> to unconditionally abort and release locks.

I am getting the same behavior with xswatch when watching on /tool/blah
as with the /local/domain/%u/blah.  The watch I added to @releaseDomain
is also not getting triggered.

Removing the wait for the shutdown_done allows it to come to completion.
 I think it may be the case that the initial @releaseDomain then
triggers the destroyDomain in XendDomain.py via refresh() which then
triggers the  destroy() in image.py.  Then, by blocking, we prevent the
original xswatch from coming to completion and block our own watch from
ever getting triggered.

My initial thought is to return to using a separately created xshandle
for my blocking channel.

If this is the case, how do we want to develop the semantics?

-John