Hi guys, I am trying to load, call and unload multiple go libs which are built with -buildmode c-shared in a c problem, it’s doable on windows, Linux and macOS ? Also I see -buildmode shared removal was rejected, what about -buildmode archive?
Happy holidays! On Monday, February 15, 2021 at 10:24:32 PM UTC+2 Ian Lance Taylor wrote: > On Mon, Feb 15, 2021 at 6:51 AM Frédéric De Jaeger > <fdej...@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/ff6279fc-6bf0-4ff9-87bf-3e83af75e79bn%40googlegroups.com.
