> 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 ...
Brice and I did a fair amount of thread safety cleanup in core at one point, but I don't recall much (if any) progress being made on the corresponding issues in facter (where they were less salient). The issues we encountered were: * Code that just wasn't thread safe * Code that was green thread safe but not fiber/true thread safe * Code that was thread safe on the ruby side but FFIed out to code that wasn't or (as with the SSL library) made different assumptions. Brice is generally a great source of insight on questions like this. As for why you might handle something like this in the leaves rather than the framework (note: I have not looked into the specific issue at hand) it can often lead to what amounts to a global lock, obviating any advantage you might expect from concurrency. Making a framework that is "thread safe" regardless what client-code-fragments which have access to shared state do ultimately tends towards "just run them one at a time in a single thread" which sort of defeats the purpose. -- M -- 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.
