I was actually really hoping for multi-threaded catalog application but I realized that 99% of the time I don't want it because I'm already pegging one processor working on the system.
Also, the code complexity that comes with that probably isn't worthwhile. HOWEVER, if we take the idea above and split everything into independent portions, spin up threads (yeah, I know) that work on that independent portion AND have a shared memory data repository that allows for cross thread synchronization....it could be really awesome. But, the big thing that I want is the ability to isolate and apply micro portions of the catalog without actually having to load the entire catalog. Trevor On Fri, May 15, 2015 at 4:06 PM, John Bollinger <john.bollin...@stjude.org> wrote: > > > On Thursday, May 14, 2015 at 2:45:52 PM UTC-5, Trevor Vaughan wrote: >> >> Hmm....what about a concept of deferred actions? >> >> I.e. Try this resource, can't do it, shove it (and it's dependencies) to >> the bottom of the stack and do everything else, then come back to it. >> > > > Yes. If there's a resource that depends on some piece of machine state > that is asynchronous with respect to catalog application, then doing > *anything* productive while waiting on that state to change is better than > doing nothing. Inasmuch as there may be plenty of other resources that can > be applied without delay, applying all such resources should be the first > choice for a time filler. > > > >> >> You could even technically have a method for simply backgrounding that >> entire resource chain. >> > > > That would be easier if resources reliably formed simple chains. In > practice, they too often form overlapping trees. That doesn't make > backgrounding impossible, but it does complicate things. > > The logical extension of backgrounding is full-fledged multi-threaded / > multi-process catalog application. In the past I have been rather leery of > that idea, but I think I'm warming up to it. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/54d7d251-d317-4bae-875f-98b56d172310%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/54d7d251-d317-4bae-875f-98b56d172310%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV-5eb8sdq6Sc9whwA-UBZ1OspM4tFHZgtG_B-K8tcSpA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
