[go-nuts] Compiling Go plugins with playground/NACL/GAE-like isolation
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Compiling Go plugins with playground/NACL/GAE-like isolation
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, > / > http://about.me/aldrinleal > > On Wed, May 17, 2017 at 7:05 PM, voidlogic > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Compiling Go plugins with playground/NACL/GAE-like isolation
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, > / > http://about.me/aldrinleal > > On Wed, May 17, 2017 at 11:55 PM, voidlogic > 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, / http://about.me/aldrinleal >>> >>> On Wed, May 17, 2017 at 7:05 PM, voidlogic 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 . >> 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.
Re: [go-nuts] Will Go 1.9 have entirely concurrent Garbage Collection?
>"Library functions that used to trigger stop-the-world garbage collection now trigger concurrent garbage collection" I wonder if there is still a way to manually trigger a complete GC pass? I have hundreds of unit benches in my code bases that call runtime.GC() before t.ResetTimer() (and t.ReportAllocs()) with the intent of reducing GC related deviation between runs. -- 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.
