Re: [PATCH][RESEND] Fix stale-state issue with 'xm dom{id, name}'

[Anthony Liguori <aliguori@us.ibm.com>]

Dan Smith wrote:

>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.
>  
>
Actually, Keir made a recent change that will cause the @releaseDomain 
notification to go out when the domain disappears which was the thing 
that necessitated polling before.

As long as Xend updates it's state on every @introduceDomain and 
@releaseDomain watch, it should always be up-to-date (barring the 
obvious scheduling race between Xend and XenStore--but that only allows 
a stale domain state window of a few 10s of milliseconds at worse).

What would be really ideal is to do away completely with the Xend 
internal state and just always pull things from the store.  This is 
probably too big of a change for 3.0 though.

Regards,

Anthony Liguori

>Thanks Ewan!
>
>  
>