For some use cases I am sure this kind of integration would be just fine. But if functions within plugins are called often enough the overhead difference between calling a function in a dynamically linked library (.so) and communicating via a UNIX socket will quickly become non-trivial. Even if you move from pipe based IPC to shared memory this is still a large gap as compared to direct calls.
For my use case, I may have resort to having users submit source code that my system then compiles (to .so) and vets (so I can black list packages, etc) if I can't find a better method of isolation. On Wednesday, May 17, 2017 at 5:20:34 PM UTC-7, Aldrin Leal wrote: > > go-plugin wouldn't work? > > github.com/hashicorp/go-plugin > > > -- > -- Aldrin Leal, <ald...@leal.eng.br <javascript:>> / > http://about.me/aldrinleal > > On Wed, May 17, 2017 at 7:05 PM, voidlogic <voidl...@gmail.com > <javascript:>> wrote: > >> Hey Everyone, >> >> I'm working on a project to allow other teams within my company to submit >> plugins that are executing as optional event handlers within my >> application. We currently support Lua but with the addition of Go plugin >> support we would like to support Go as well (our app is written in Go >> itself). >> >> The new plugin package looks like it will work well: >> https://golang.org/pkg/plugin/ >> >> The only caveat is it would be nice to have the plugins have similar >> filesystem, unsafe, etc isolation that the playground has. One idea would >> be to try to maintain a fork of Go that allows these GOOS=nacl mockups to >> be enabled for amd64 plugins- would that work or does a plugin share a >> runtime with the loading application? I don't think pure NACL with work >> without linking the NACL loader into the application... >> >> How does Google's app engines isolation work? A forked Go runtime? With >> the difference that no part of the app needs privileges (unlike here were >> the app doing the loading should be privileged) >> >> If anyone has thoughts on loading plugins with some isolation, I would >> love to hear them. Thanks! >> >> -Tylor >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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. For more options, visit https://groups.google.com/d/optout.