On Mon, Feb 15, 2021 at 6:51 AM Frédéric De Jaeger <fdejae...@novaquark.com> wrote: > > On Saturday, February 13, 2021 at 4:21:34 PM UTC+1 Ian Lance Taylor wrote: >> >> >> >> > I was naively assuming that the unloading issue is easy to tackle when the >> > runtime is not shared between .so. Is it true ? >> >> No. The current Go runtime has no ability to shut down all >> goroutines. If any goroutines are left running, and the plugin is >> unloaded, the program will crash. >> > > I was not assuming a synchronous uncooperative way for the runtime to kill a > running goroutine. I was more thinking about some cooperative strategy. Like > a running go routine could check sometimes (maybe in the function prologue, > or when doing an allocation) that it is time to die.
I don't see how that could be completely reliable, especially when Go code calls into C code. For something like this Go aims for solutions that are 100% reliable. > Anycase, that could be also a constraint of the business code in the plugin. > Like in C, they are not supposed to be actively running when the .so is > dlclosed. > In fact, what happens in practice today if we dlclose a plugin that has no > running goroutine (and also no cgo invocations). Does it "work" somehow ? > Are we leaking threads, waiting on some dead semaphore or something ? The current Go plugin support does not support calling dlclose on a plugin. > This `ld` flag makes me think of another approach. Maybe it is ok to just > turn off the effective unloading of the .so (with that ld flag). So dlclose > is no-op. But if the business code takes care of cleaning most of its global > state, maybe the gc has the opportunity to return some memory back to the OS > (well, since the gc is not moving stuff, maybe the hope is slim, I don't > know). The Go runtime does already return some memory to the operating system over time. It won't return all of it, though. > By the way, what the most efficient way to detect if two runtime are being > instantiated ? Something like a debug log that is supposed to happen once, > or a similar trick. I don't know of a way to do this. Ian -- 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/CAOyqgcX08rd_Gkg_e_QLqDu%2BodFCK6SD13BLoSL0HJLKpQ0z2A%40mail.gmail.com.
