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` ch
ent: 31 August 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
: [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 others on the thread have already given: use a `sync.Map` to associate each task ID with a small struct containing a `context.
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
Appreciated, thanks Brian and Ian.
On the subject of sync.WaitGroups, I haven't tackled this yet for my use
case, but will use the opportunity to brainstorm some options, if that's
okay. I want to be able to terminate each worker independently of others
(i.e. close on worker, wait for it to finish
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 h
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 iss
10 matches
Mail list logo
