On Tuesday, February 9, 2021 at 2:46:33 AM UTC+1 Ian Lance Taylor wrote:
> > > Thanks, you may be correct: it may be possible to hide all symbols > other than the ones that are intended to be exported to the C program. > If it is possible to do that reliably in all cases, then the effect > should be that if you link against multiple shared libraries, each > will have an independent Go runtime. The program will wind up with > different Go heaps and different garbage collectors competing with > each other. The result will be inefficient, sometimes alarmingly so, > but I don't immediately see any reason why it wouldn't work. > > No bad surprise expected from other kind of uniqu per process resources ? (signal? ...) I suppose you mean other kind of inefficiency than the basic ram usage ? I've observed that when I run several CPU intensive go apps on the same host, the cumulative GC pause (Memstats.PauseTotalNs) raises dramatically (not linear in the number of go process running). But in more gentle scenario, where the go plugin rarely runs, do we hit those inefficiencies ? At the moment, go can't be used reliably as a tool to write C plugin for a generic C host. Because of the runtime constraints, and the unloading issue. I was naively assuming that the unloading issue is easy to tackle when the runtime is not shared between .so. Is it true ? I can see a difficulty when there are running go routines doing cgo invocations (and we can probably fail/abort/crash in this case) . Apart from that, I have the feeling this should be easy to cleanup all the runtime ressources (memory, threads). I suppose this kind of cleanup logic was never written because exit(0) does the same job. IMHO, being able to write generic C plugin in go, would be a good selling feature (I would appreciate it as much as all the people here https://github.com/golang/go/issues/11100). So, suppose we implement that feature by hiding/unsharing the runtime (assuming it works and we fill in the missing pieces) The question is how bad would be that solution compared to the absence of that feature ? Are there really some business usage of the current existing feature ? (people really loading several `c-shared` go .so and expecting to share the runtime) What about yet another build mode like `c-shared-private-runtime` ? unloading would be only implemented with this build mode. A last technical question, do you link the shared object with the ld flag `- z nodelete*` *(which turn dlclose into no op). > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f1332fdc-67c4-492e-9810-02cfc95eda7bn%40googlegroups.com.
