I'm was only considering the case where a plugin could access the memory of something it wasn't supposed to.
On Tue, 29 Nov 2016, 20:35 Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > On Tue, 29 Nov 2016 01:14:40 -0800 (PST) > Dave Cheney <d...@cheney.net> wrote: > > > > All the plugins will be sharing the same memory with no control > > > stopping one from accessing the memory and resources of another. > > > Furthermore you wont' be able to unload or reload an > > > "application" (plugin). > > > > This may not be correct. Assuming that they plugin does not use the > > unsafe paxkage then the memory safety guarnetees of Go should apply. > > A plugin would bit be able to discover a reference to another value > > unless it is explicitly provided with one. > > What would happen if a plugin panic()s or merely eats up inordinate > amounts of memory? The OS (usually) has tricks up its sleeve to handle > all such cases. > > I know I'm stating the obvious things you're definitely familiar with > -- just trying to highlight the process separation implemented by a > typical general-purpose OS is still a real thing. > -- 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.
