----- Original Message ----- > > 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.
for facter I'd think this is totally the right way to go. Need to consider the audience, expecting our users to do locking and semaphores is just crazyness the Facter framework should just make it safe, the user experience should be that simple code behaves well and can add a fact. I recall at least one instance of a fact that did its own locking caused me frequent deadlock issues when using facter as a lib in other code, once I ditched that fact the problem went away. -- 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.
