On Sat, Feb 13, 2021 at 1:53 AM Frédéric De Jaeger <fdejae...@novaquark.com> wrote: > > 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 ?
Probably not. I would still be concerned about surprising behavior. > 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. Yes. > 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 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. Yes, goroutines currently calling into C code are a particular problem, but they are not the only problem. > 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. I tend to agree that if people want to use Go code as plugins to a C program, they would expect those Go plugins to operate independently. But I think that many people would be disappointed by the effects on resource usage, which they would have no way to mitigate. So we would have a feature that would make people unhappy in practice. > A last technical question, do you link the shared object with the ld flag `- > z nodelete` (which turn dlclose into no op). As far as I know we do 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/CAOyqgcUAE%3DU_x3Ry-OaXPwkKLVeAuQDbMq9YPUQcUkTXpH-MoA%40mail.gmail.com.
