Title: Message Title
Thomas Hallgren commented on PUP-9932
Re: Make 3x functions loaders thread-safe
Making the Puppet runtime threadsafe is something that would strongly advice against with a huge red flag. Do not do this! There is nothing in the runtime today that was created with concurrency in mind and there's a whole slew of shared resources that would need to be protected in order for this to work. For instance, there's just no way that threads can share the same set of loaders. Not only are the loaders themselves unsafe but also most of the objects that they load. Several objects cached values on demand. Nothing in there takes into account that multiple threads may access these objects simultaneously. The hiera lookup system is not threadsafe. The serialization is not threadsafe. The parser is not thread safe. And so on and so forth (because nothing is). The really horrible thing is that even if all of the Puppet runtime is really made threadsafe, the next problem is that no code in any module was even been written with concurrency in mind. No module out there can be considered not threadsafe. Also, what about the third party gems that puppet make use of? Do they declare that they are safe to use in a threaded environment? If they don't, then rest assured that they cannot. I think that a much safer approach would be to abandon the use of JRuby and instead direct all resources to use a pool of MRI instances. They can be initialized some degree (initial set of classes loaded etc.) and there must be a reset to that wellknown state after a pooled instance has been used. But there would be absolutely no threading going on. I wasn't aware of the work of making the Puppet runtime threadsafe until yesterday, hence my late input on this.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
