the proper behaviour when monitoring for a change in some variable is this pattern, _always in this order_

1) register your watch.
2) check the current state.

you may get an extra notice (ie: you get a change notification that was sent before you do your current-state check) but you can never have an out-of-date value.


if dconf is to have non-blocking watches (which it ought to) then there is a problem: the 'check current state' will likely complete before the watch is fully registered with the bus daemon.  consider the case of process A starting up while process B is already running (and making changes):


 DB starts with /some/key = false

 - process A says "watch" -> async dbus AddMatch sent
 - process A reads /some/key, and it is 'false'
 - process B changes /some/key to 'true' (sync, async, whatever)
 - dconf writer sends change notification for /some/key
 - dbus daemon emits changed signal to nobody (since nobody is watching yet)
 - dbus daemon receive AddMatch message and handles it

now the key is set to 'true' but A thinks that it is 'false'.

this is an *extremely* narrow window.  in practical reality you'd probably have to get extremely unlucky for this to even be vaguely possible.  unlucky happens, though, so it ought to be fixed somehow.