Async watches and their creators

[Gustavo Niemeyer]

> The invoker is trying to sync state to behavior, if the sync isn't complete
> when control is returned by the invoker, it has no way of proceeding easily
> based on the current state if it depends on the async behavior.

Yes, the problem as I tried to explain yesterday online, though, is
that this is an unrealistic assumption.

Simple example where your proposal *would* work:

A) Class A sets up state in ZK
B) Class B sets up watch on node N, doesn't fire deferred
C) Class B gets first state set by A, fires deferred

At the end, we got the state fully synchronized, as you were wishing for.

Now, let's invert things.

B) Class B sets up watch on node N, doesn't fire deferred
C) Class B gets first state set by A, fires deferred
A) Class A sets up state in ZK

Now, the state is *not* fully synchronized, because B will fire a watch
again to process the changes done by A.  The only thing I did was to
reorder calls in the source code.

I'm concerned about getting into rabbit hole where we have to call
things in the proper order by understanding how the internals work
so tests can pass.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter