Thanks for the detail. We cannot change the calling program, just conform to it's API, so it's one function call per email send event and each in it's own (new) thread.
On Thursday, 20 October 2022 at 12:28:12 UTC+1 Konstantin Khomoutov wrote: > On Wed, Oct 19, 2022 at 06:28:20AM -0700, Peter Galbavy wrote: > > > I have built a shared lib in Go to replace an old thing we use to send > > email - mainly to modernise things and add TLS and authentication. We > run > > each call to the entry point in it's own thread in the main program. > > > > I am both curious but also concerned about what happens here with go > > runtimes. I presume each thread has it's own runtime, and on exit it is > > torn down, but I may be wrong and would like to know more. > > As already hinted, there's only a single instance of the Go runtime > powering > your shared library after it got loaded and initialized. Basically it's the > same thing as a regular Go program would call into a C library via cgo, and > that library would be using multiple running threads which could access the > data passed from the Go side and even call back to the Go side. > > To have less cognitive burden, I would recommend to move one step further > and > make your library have a single entry point which would accept a job unit > and > process it concurrently with any other job units - that is, defer > concurrency > to the Go library. > > If you're basically already doing something like this and are only > concerned > about what happens when you call to a Go library from multiple threads, > then > the answer is - apply the usual logic: all variables which are local to the > function call chain which got called from a thread are safe as they are not > shared from the other call chains. If these call chains happen to share > some > state in the library, you have to guared the access to it - in one way or > another - using channels or resorting to mutexes etc. > > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d5f8e7f8-847a-4bbb-bc38-1d3c8ac05466n%40googlegroups.com.