Async watches and their creators

[Kapil Thangavelu]

Excerpts from Gustavo Niemeyer's message of Wed Apr 20 10:57:24 -0400 2011:
> > The watches are permanent, so even in the inversion there's a D) where
> > the watch fires again, but that doesn't matter at all to the original
> 
> Yes, but that D) happens in background, asynchronously, which is
> exactly the problem you're suggesting we solve.  So the proposal
> works with A+B+C but does not with B+C+A, which was my point.

Okay, but my point was it doesn't matter to the invoker, its moved on
at B in either sequence, and the underlying assumptions of this example
are invalid as we're never waiting on zk watches to fire. The reordering
of events is immaterial as long as the watch callback handles the
whatever the current state is.

> 
> > the first watch invocation for units assigned to a machine, or related
> > services of a unit, happens based on the current state not the zk
> > watch firing.
> 
> Yes, the first invocation necessarily happens based on the current
> state.  The point being raised is that the current state is not
> necessarily the one we care about.
> 

My point is that the invoker don't care about the state, nor should it, 
just that the state is current as of the invocation, which is what I want
to solve.

cheers,

Kapil