Re: [Xen-devel] XenStore Watch Behavior - John McCullough - com.xensource.lists.xen-devel

10 messages in com.xensource.lists.xen-develRe: [Xen-devel] XenStore Watch Behavior

From	Sent On	Attachments
John McCullough	26 Aug 2006 13:31
Keir Fraser	27 Aug 2006 07:56
John McCullough	28 Aug 2006 17:48	.diff
John McCullough	28 Aug 2006 17:51
John McCullough	28 Aug 2006 19:22
Keir Fraser	28 Aug 2006 23:26
Ewan Mellor	29 Aug 2006 02:15
John McCullough	29 Aug 2006 12:11
Ewan Mellor	29 Aug 2006 12:42
John McCullough	29 Aug 2006 16:34

Subject:	Re: [Xen-devel] XenStore Watch Behavior
From:	John McCullough (jmcc...@cs.ucsd.edu)
Date:	08/29/2006 04:34:46 PM
List:	com.xensource.lists.xen-devel

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