Async watches and their creators
gustavo.niemeyer at canonical.com
Tue Apr 19 20:21:42 UTC 2011
> This is bit technical, regarding the ensemble internals.
Sorry for the delay. I had a first pass and was thinking about it as
we discussed, but then forgot to come back.
> The problem arries in that the apis which setup these watches are
> returning after they have setup the watch, when as result of creating
> the watch they have pending initialization work outstanding. This
> leads to some timing issues when dealing with initilization. I've
> identified this problem in a few places in the codebase.
> - ensemble.unit.lifecycle.UnitLifecycle.start
> At the return of start method, there is still pending activity in the
> form of the initial the unit relation watch processing occuring in the
One thing that makes the proposal you follow up below not entirely
clear to me is that this work isn't *really* initialization. This is
going to be persistently monitoring the state of the system and
reacting to changes by applying the deltas in the system. This means
that if those changes happen not in the first call, but in the second
one, it's totally fine for the system. For that reason, it's not
clear that having special behavior taking place on the very first call
is the right thing to do.. will it just make tests easier to write, or
will it more easily hide bugs since the system can in fact postpone
Not saying it's not a good idea, but it'd be nice to at least talk a
bit more with higher bandwidth about the issue (a voice call) to make
sure there's no underlying problem which we'll be hiding with it.
More information about the Ensemble