As I mentioned before go-plugin uses RPC/IPC which is much slower than shared/dynamically linked libraries.... So if you didn't have a high performance use case, that would probably work.
On Thursday, May 18, 2017 at 3:25:49 AM UTC-7, Aldrin Leal wrote: > > what if go-plugin + docker? I think you could block networking altogether. > Wiring those two wouldn't be a problem if you use things such as > go-dockerclient > > -- > -- Aldrin Leal, <ald...@leal.eng.br <javascript:>> / > http://about.me/aldrinleal > > On Wed, May 17, 2017 at 11:55 PM, voidlogic <voidl...@gmail.com > <javascript:>> wrote: > >> 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> / http://about.me/aldrinleal >>> >>> On Wed, May 17, 2017 at 7:05 PM, voidlogic <voidl...@gmail.com> 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. >>>> 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...@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.
