Let's talk retries

[Katherine Cox-Buday]

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 <william.reade at canonical.com> writes:

> On Tue, Aug 9, 2016 at 10:17 AM, roger peppe
> <roger.peppe at canonical.com> 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