On Wed, Sep 28, 2011 at 09:56, Ken Barber <k...@puppetlabs.com> wrote:
> So I was looking at a patch from mkincaid & Krzysztof Wilczynski > https://github.com/mkincaid/facter/blob/ticket/2847/lib/facter/mounts.rb#L69-71 > > Which is for ticket: > http://projects.puppetlabs.com/issues/2847 > > When talking to KW he said he ran into thread safety issues, hence why > he used a mutex. Has anyone seen this before? Its a concern because we > should be fixing cause not symptom ... Generally, I think anything that we accept into core should be written to be thread safe by not touching any shared resources, rather than by locking around shared structures... ...ah, and that is why they have trouble. They are trying to statically discover the list of data, then bind facts to those values once, rather than trusting to the cache layer in facter. They should pull all the logic into the setcode block, or a helper called from it, and accept perhaps calculating it twice. > There is some smell of it here: > http://projects.puppetlabs.com/issues/4246 Very different issue: since we do actually thread our master, we need the *infrastructure* around Facter to be thread-safe. Which is: in our code loading facts we need to be thread-safe, but for writing a thread you shouldn't need to care. Also, you won't be able to reproduce that specific failure without JRuby. Everything else has pretend threads and would make it stupidly harder to hit this failure mode. (...or is passenger, which isn't threaded.) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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.
