EM> The thing is, it solves the problem by making sure that SrvDomain
EM> can cope with stale domains being returned by XendDomain, but I
EM> _really_ don't want XendDomain to be returning stale information
EM> in the first place.
I agree. I recently submitted a patch that would cause XendDomainInfo
to destroy itself whenever it realized that it was stale. Christian
didn't like the idea of random places modifying the Xend state. So,
in this patch, I just handled the stale state instead of returning the
bogus information, and without modifying the state itself.
EM> I've been trying to decide how easy it would be to fix the
EM> underlying problem -- if it's going to take a long time, then I'll
EM> apply your patch as a workaround, but I hope to solve the problem
EM> more definitively.
I think the solution (or best fix) is to standardize on the fact that
we always update domain information right before we return it, and
purge that information if needed. I think that "xm list" triggers
this somewhere deep inside xend, as I can always purge the stale data
by running an "xm list". This tells me that some async signals aren't
always being sent to clean up, which means "xm list" has to trigger
it. I *think* Anthony had a comment about polling being necessary in
this case for some reason, so perhaps he can chime in and explain.
Thanks Ewan!
-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel