Issue 10602043: Document locking concerns around SetConfig. (Closed)
DescriptionDocument locking concerns around SetConfig.
Based on an email exchange where Roger Peppe provided helpful information.
Here are the parts on which I based the documentation change:
> Do we want consistent images of an environ and its config, so that a
> provider operation concurrent with a config change doesn't get a view
> that's nonsensical in some way? Or are the locks just there to prevent
> undefined behaviour at the language level?
The locks are there principally for the latter, yes, because in general
we allow methods to be called concurrently on an Environ
and allowing concurrent access to fields invokes undefined behaviour.
> When we release an environment's lock between reading multiple
> attributes, is there a risk of reconfiguration happening inbetween, and
> do we mind? It'd be great to have the reasons explicit in the code.
In the most general case, there is such a risk, but we take care not to
share an Environ between concurrent workers, so any individual worker
can decide whether it is appropriate to call a method or function which
may call SetConfig (it's free to use a mutex itself if it needs to).
There are a few more such places than there used to be
(environs.FindBootstrapTools and environs.EnsureCertificate being two),
so it's definitely worth being aware of this potential issue.
https://code.launchpad.net/~jtv/juju-core/locking-comment/+merge/171494
(do not edit description out of merge proposal)
Patch Set 1 #
Total comments: 1
MessagesTotal messages: 5
|
||||||||||||||||||||||||||||
