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/20221020112742.n35ewbvzb2t72f7s%40carbon.
