On Tue, Aug 31, 2021 at 8:58 AM Kevin Chowski wrote:
> To the original poster: can you just declare your own Logger-like interface
> and allow users of your library to pass whatever logging implementation they
> have? In what ways are you thinking that you're forced to be coupled with the
>
Hi all.
We have a java web application calling C program which in turn using go
program as a library. The go library was build with --buildmode= c-shared.
Now we got a crash with the application, but there is no call stack for go
program. We are thinking that it might be that java signal handler
Can you clarify why having log.Logger be an interface would be helpful?
Any library can define their own Logger interface with the same methods as
the log.Logger type (e.g. Printf, Fatalf), and that would allow that
library to take a reference to some generic "logging implementation"
without be
Maybe it is worth checking out:
https://github.com/go-logr/logr
On Sunday, August 29, 2021 at 8:10:54 AM UTC+2 Amnon wrote:
> Yes, this is a massive pain.
>
> The standard library's log.Logger is not an interface, despite ending in
> er.
>
> If it was an interface, it would be easy for third p
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
> I want to be able to terminate each worker independently of others
> (i.e. close on worker, wait for it to finish its tasks, but allow
> other workers to run if they haven't been signalled to stop).
The solution I use is to have each worker take two parameters:
- a channel that will be closed
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
