I see the pattern used in ErrGroup pipeline a lot:
c := make(chan result) const numDigesters = 20 for i := 0; i < numDigesters;
i++ {
which leads me to question the effectiveness of this design. Sure, you bound
the number of routines, and this should probably be something like cores * 2,
but in a complex application this is localized, so using this pattern in
multiple locations will lead to cpu saturation.
Is there anything like an execution pool built into stdlib. I know it is fairly
trivial to write but I was looking for a standardized version.
> On Oct 25, 2018, at 5:02 AM, Sebastien Binet <[email protected]> wrote:
>
> Hi Andrew,
>
>> On Thu, Oct 25, 2018 at 11:56 AM <[email protected]> wrote:
>> A mini library I came up with, let me know what you think:
>>
>> https://github.com/andrewchambers/bundle
>>
>> Introduces the concept of a bundle of goroutines.
>>
>> - All goroutines part of a bundle share a context.
>> - The context is cancelled automatically when the bundle is garbage
>> collected.
>> - You can manually wait for a bundle to exit.
>> - You can manually cancel a bundle.
>
> it's well written, but at first sight, it seems it has a lot of overlap with
> x/sync/errgroup:
> - https://godoc.org/golang.org/x/sync/errgroup
>
> could you summarize why someone should use "bundle" instead of "errgroup" ?
> ie: what's the use case that's easier to handle with "bundle" ?
>
> cheers,
> -s
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
