Andrew's queue is certainly nice, but I agree with the points Roger is raising:
1. Go's idiom for coordinating concurrent operations are goroutines and channels. 2. Sticking to these idioms makes it much easier to compose parts into a whole (if only because the language strongly bends code that way). As a matter of opinion, I also dislike having to instantiate structs to encapsulate logic; I would rather write the logic inline, or in a closure -- possibly in a goroutine. William Reade <[email protected]> writes: > On Tue, Aug 9, 2016 at 10:17 AM, roger peppe > <[email protected]> wrote: > > BTW I'm not saying that a timer queue is never the correct answer. > In some > circumstances, it can be the exactly the right thing to use. > > > Yeah -- the context here is that katco has been looking at the > provisioner, and I think a timer queue is sensible there. Firing off > goroutines for every machine is not necessarily bad by any means, but > it *is* somewhat harder to get right in every circumstance (e.g. what > happens when a machine is removed while that other goroutine is > working on provisioning it?). > > There are certainly many places where a single retryable op *is* the > only important thing and there's no call for a control loop. I'm not > suggesting we should always use a queue; but I'd tend to encourage it > whenever we have a component dealing with many similar retryable > tasks. (I definitely should be using it in dependency.Engine, for > example.) > > Cheers > William > -- Katherine -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
