Awesome, thanks so much for the help here! Learned a lot from the input and
code examples. :)
Much appreciated!
On Thu, 2 Sep 2021, 15:49 Bryan C. Mills, wrote:
> On Wed, Sep 1, 2021 at 5:55 PM wrote:
>
>> Thanks Bryan, especially for the code example.
>>
>>
>> Would using a sync.WaitGroup in
On Wed, Sep 1, 2021 at 5:55 PM wrote:
> Thanks Bryan, especially for the code example.
>
>
> Would using a sync.WaitGroup in place of the `done` channel in your
> example be overkill? Just exploring what’s possible here for my own
> education.
>
Using a `sync.WaitGroup` in place of the `done`
gust 2021 20:22
> To: golang-nuts <mailto:golang-nuts@googlegroups.com>
> Subject: Re: [go-nuts] Managing perpetually running goroutines
>
> For the specific case of managing long-running polling- or pubsub-based
> tasks, I would suggest basically the same pattern that other
] Managing perpetually running goroutines For the specific case of managing long-running polling- or pubsub-based tasks, I would suggest basically the same pattern that others on the thread have already given: use a `sync.Map` to associate each task ID with a small struct containing a `context.CancelFunc
For the specific case of managing long-running polling- or pubsub-based
tasks, I would suggest basically the same pattern that others on the thread
have already given: use a `sync.Map` to associate each task ID with a small
struct containing a `context.CancelFunc` and a channel that can be used
For that case, I'd suggest you pass a channel to each worker. It can
either close the channel, or send a specific message down it, to indicate
its termination.
This may also be an X-Y problem. Generally speaking, "worker pools" are an
anti-pattern in Go. The startup and termination overhead
Also: you can use the same context for all the workers (if that's
appropriate); or if you want each worker to have a different context, you
can make those contexts children of the same top-level context. In that
case, you only need to cancel one context and all the workers will stop,
without
On Sun, 29 Aug 2021, at 10:45 PM, sansaid wrote:
> Hello,
>
> Does anybody know of some reference code or common patterns I can use to keep
> track of worker goroutines? For context, I want a user to be able to issue a
> "stop" command using a CLI tool which will prompt my server to gracefully
Hello,
Does anybody know of some reference code or common patterns I can use to
keep track of worker goroutines? For context, I want a user to be able to
issue a "stop" command using a CLI tool which will prompt my server to
gracefully terminate one of my workers.
For example, when a user
