On 23/07/10 17:32, Markus Roberts wrote: >> +1, that's the patch I dreamt I could send :-) >> >> Thanks! > > And thank you...this is definitely the sort of problem where > pair-programming is called for. > >> The only drawback is that we might keep a reference to a given >> known_resource_types objects preventing the GC to get rid of it long >> after a compilation has finished. Imagine a case where we have a >> thread-pool, when the thread will enter back the pool, it will still >> have this reference. If the manifest change then this >> known_resource_types reference will still be live. >> This might not be a problem in production, though. >> >> Can't we imagine to have a thread environment "release" mechanism at the >> end of a network request lifecycle? Maybe in P::N::Handler#process? >> >> What do you think? > > I agree that we need something along those lines, I'm just not sure 1) > where to put it and 2) if simply clearing the thread_var would > suffice. > > One thought I had had was that the first time we compile we are > clearing an already nil thread variable (the change to > Puppet::Parser::Compiler.compile), and we are concerned about > retaining a reference after compilation -- which suggests perhaps that > the nilling should be done at the _end_ of compilation (in an ensure) > rather than at the start. In other words, rather than thinking about > that as a "clear the area so we can work" we should think of it as > "throw out our trash when we're done."
The thing is that a thread might do other thing requiring the known resource types beside compiling (I don't know what, maybe a resource indirection or sth). That's why I proposed to perform the cleanup when the thread exits Puppet (or near this time). > I'd like to assure myself somehow that nothing in the chain is > retaining a copy of known_resource_types though. This could be done > by inspection (which is what I"m planning on doing) but it's also > looking like we're backing into a WeakRef pattern. I know ruby has > them but I haven't used them extensively and I'm not sure how well / > consistently they are supported across version or implementation (I > know the MRI style of implementation wouldn't port cleanly to JRuby, > for example). Java has the notion of Weak references too, so I assume JRuby would map a ruby WeakRef to a java one. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
