On Sun, Oct 2, 2022 at 11:26 PM Jason E. Aten <j.e.a...@gmail.com> wrote: > > I've tried to come to grips with the lovingly detailed > https://pkg.go.dev/os/signal preamble, but I'm going to ask to get the > experts thoughts. On Linux, my scenario is: > > I have a main program main.go. Via CGO, it loads libmyc.so, a large, legacy, > C .so shared library. Obviously the executable of main.go will contain a Go > runtime. > > I have a separate c-shared library, as a libmygolib.so, that I've written in > Go. Since > it is a c-shared .so, it will contain a Go runtime as well. > > Now libmyc.so would like to load and use libmygolib.so. > > As a result I'll have two Go runtimes in the same process, possibly fighting > over > signal handlers. > > I don't really care about profiling here; I can run them independently for > debugging/tuning. > > Am I going to get signal handling problems? Is there anything I can do with > the signal handling to avoid them?
It's possible. On Linux the dynamic linker may override all the shared library symbols with the symbols in the main programs. I'm not sure, and in general it will depend on how the main program is linked. If it does override, then the duplication of the runtime may not matter. I'm not really sure, though. > Is there some way to build a c-shared library so it will not have the Go > runtime in it, and have the dynamic linker find the single Go runtime at load > time? There is not. 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/CAOyqgcV3TtdtTTASXMDQMibnSri15PfCETNZsCwxL7tL0hDSPg%40mail.gmail.com.
