> > - # The list of directories to search through for loadable plugins.
> > + # features uses the autoloader which causes a loop so avoid trying to
> > + # ask Gem for its path during feature loading.
> > + #
> > + # We're using a per-thread cache based on the code in
> > #module_directories.
>
> Why are we using a per-thread cache?
This pattern is common throughout the compilation phase and is crucial
to the semantics of a puppet compile.
* If we don't cache, we could compile part of a catalog with one
set of objects and the rest with another, leading to an
incorrect result. Think of compilation as a function which
takes the system state (paths, modules, etc.) as arguments:
function compile(manifest,modules,gems,...) --> catalog
Clearly, you want to establish the value of all these arguments
before evaluating the function body, and hold their values
constant throughout; if they can change mid way, who knows what
might happen?
* The cache needs to be per-thread since different threads might
be compiling at the same time with different values (e.g. in a
different environment).
* We clear the caches so that 1) external changes are noticed
promptly, 2) assumptions don't bleed over from one compile to
another (possibly unrelated) one, 3) so that we don't leak
memory.
This probable should be documented somewhere, but not on each instance
of the pattern.
-- Markus
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
