| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] XenStore Watch Behavior
On Tue, Aug 29, 2006 at 12:12:11PM -0700, John McCullough wrote:
> When I began I had to try to extract the semantics from the code.
Yes, that's quite a common thing to need to do at the moment! Thanks for all
your efforts in documentation -- it's appreciated.
> I wrote the API section in
> http://wiki.xensource.com/xenwiki/XenStoreReference which needs to be fixed
> and better explained. Once we establish what the correct usage pattern is I
> will try to reproduce it on the wiki page.
>
> If I use an independently created xshandle in my blocking communication
> channel code, it works in all cases. If I use the xswatch method, it is
> failing in the destruction case.
>
> If the usage model that is desired is to use a single xshandle in a
> given process, then we should change the semantics and/or document the
> relevant functions. Also, I would like to find out why my watch is not
> executing in the destruction case.
>
> A distilled version of the debugging log that I have is:
> (XendDomainInfo:1424) XendDomainInfo.destroyDomain(6)
> (xswatch:65) xswatch triggered on @releaseDomain
> (image:397) hvm shutdown watch unregistered
> (xsblockingchannel:79) waitFor executes and blocks
Can I see the code? This doesn't mean an awful lot without seeing what you've
changed.
> I haven't been able to get xswatch to trigger on any further writes to
> my node in the xenstore via xenstore-write. My only guess is that
> during the domain destruction that all watches within a domain's path
> are unwatched.
You will certainly lose a watch on anything in the domain's path eventually,
because Xend and the hotplug scripts will be cleaning up behind the domain.
You should get one final watch fired when the path disappears.
> The surface-level solution that I can think of is to
> move the qemu-dm/image destruction earlier in the domain destruction
> process. Are there other solutions?
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.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home