golang
plugin: add support for closing plugins
Adding support for closing plugins would give a simple way to do hot code reloading in long running applications like web servers.
This would add another method to src/plugin/plugin.go and a new file src/plugin/dl_close.go that would handle closing the dlhandle and destroying the go symbol map.
It would also add the handle as an un-exported unsafe pointer to the go plugin struct.
The main issue is how to signal that a plugin has been closed without breaking API compatibility. Currently the plugin has a channel called loaded which is closed when the plugin is loaded. The simplest solution is to add another channel which is closed when the plugin is closed, however this doesn't seem very 'neat' to me.
I don't see how this could be implemented safely. Other Go code could have references to functions and symbols loaded from the plugin-would unloading the plugin make those dangling references, or delay the unloading of a plugin until all the references have been reclaimed? Neither sound workable.
Would it be possible to make close fail until the reference count of all symbols in the plugin reached 1, so that the plugin itself was the only structure that held a reference?
Alternatively you could have a different function which checked whether references to the symbols existed and if there were none close the dlhandle, leaving the destruction of the plugin object and any other references up to the program. While this is far from ideal I think with adequate caution it could be a workable solution.
Would it be possible to make close fail until the reference count of all symbols in the plugin reached 1, so that the plugin itself was the only structure that held a reference?
This is spinny and racy.
Alternatively you could have a different function which checked whether references to the symbols existed and if there were none close the dlhandle, leaving the destruction of the plugin object and any other references up to the program. While this is far from ideal I think with adequate caution it could be a workable solution.
This sounds like a finaliser, with the associated problems of finaliser non determinism.
Your proposal is to add a way to free resources associated with a plugin. If this is delegated to a finaliser it becomes non deterministic when this freeing occurs as finalisers are not guaranteed to run promptly, or indeed, at all.
I'm not suggesting that it's run automatically by the GC, or in a defer (unfortunately).
I'm suggesting that if the needs to be unloaded that the developer will keep track of references to it's symbols then when they no longer need them destroy the references then explicitly call close.
In that situation they will either forget to call close, leaving the handle open, close successfully or attempt to close when there are still references which will fail. It could possibly fail with a panic rather than a plain error as attempting the close a resource that still has a reference is a pretty big bug.
I don't see what issues this approach has beyond reliance on the developer to not make mistakes. It does introduce a need to keep track of references which is far from perfect and not something I'd like to introduce to go. However I think that it's worth having this for those that want to use it and understand the additional complexity it introduces.
What if the plugin started a goroutine?
Go as a language and a runtime environment tends to avoid providing facilities that are easy to get wrong when getting them wrong causes the program to crash or behave unpredictably. I don't see how to make this at all reliable, so to me it doesn't seem to be a good fit for Go.
goroutines would have to be handled in the same way, requiring the developer to close them.
I can understand not wanting to introduce functionality that's easy to misuse. I just think that it's better to have the ability to do it if you know what you're doing. I guess it does go against the philosophy of go though.
How can you close a goroutine? The runtime doesn't give you any way to get a handle or an identifier for a goroutine?
On Tue, 23 May 2017, 09:54 Zac Pullar-Strecker [email protected] wrote:
goroutines would have to be handled in the same way, requiring the developer to close them.
I can understand not wanting to introduce functionality that's easy to misuse I just think that it's better to have the ability to do it if you know what you're doing. I guess it does go against the philosophy of go though.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-303251214, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA7TSJ5h7YYZU1PZDXlrNZfjSaaifks5r8iBGgaJpZM4Ni-0b .
I took a quick look at runtime but couldn't find where exactly the goroutine is created. Are goroutines not closed when they return?
Yup, a goroutine dies/quits/goes away when the function that was passed to the go statement returns. So that leaves the problem of ensuring every goroutine that may have access to a symbol from a plugin must exit before the plugin can be unloaded. This means either finalisers, which won't give you a timely response, or manual bookkeeping, which as Ian said is unreliable.
On Tue, May 23, 2017 at 12:16 PM, Zac Pullar-Strecker < [email protected]> wrote:
I took a quick look at runtime but couldn't find where exactly the goroutine is created. Are goroutines not closed when they return?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-303271038, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA-7gIyQn1lrDQJPC5XHyF1Oe4u_Mks5r8kGDgaJpZM4Ni-0b .
Ok, that's what I thought.
I personally think that manual bookkeeping wouldn't be too bad. If you're writing something designed to be loaded/unloaded you're probably going to make sure you keep track of references and goroutines as is.
I'm trying to think whether there's a better way to do this. I guess it's not something other languages have had problems with.
I have another idea for how this could be solved, it's not simple though and I'm not sure whether it would make sense.
Basically I think it would be possible to implement a compile-time check that ensured there was no possibility for a dangling reference when a program was closed.
The compiler could check to see if close was called on any plugin object in the program. If it was we'd find all of the lookup calls associated with that plugin and determine whether there were any paths that could leave a live reference when or after closed was called.
I have no idea how you'd implement this or whether it'd be fast enough to be viable. Just an idea.
What about having the GC close any plugins that are no longer referenced?
That's what the JVM does. And forcing a full GC whenever Go code must be unloaded is not hard.
That's a finaliser.
On Sun, 4 Jun 2017, 11:45 Demi Marie Obenour [email protected] wrote:
What about having the GC close any plugins that are no longer referenced?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-306012057, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcAyloFURN5wCFLtkaTGCb3LPug7v7ks5sAgwmgaJpZM4Ni-0b .
It feels like somewhere between rusts ownership system and a finaliser.
On Sun, 4 Jun 2017, 13:48 Zac Pullar-Strecker [email protected] wrote:
@davecheney https://github.com/davecheney Any comment on making it a compile-time check?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-306016154, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA5tJxnFTW952qctOd7bRsZVmylDHks5sAikQgaJpZM4Ni-0b .
I don't see how it's like a finaliser, at least in the aspect of non-determinism.
It is pretty similar to rust's general approach; I don't think that's a bad thing though.
If I load a plugin foobar-v1.so that has foobar() I could wrap it in my own functionfoobarWapper() that increments/decrements a waitgroup on every call. Things that want to call foobar do so accessing foobarWraper atomically and calling it. Later on I load foobar-v2.so, wrap it in a new wrapper, and atomically swap it out for out for the old foobarWrapper. Now I can use the old foobarWraper's wait group to make sure no one is active and when that is the case call dlclose using cgo.
This all would depend on the user not creating goroutines, but that could be checked for at the source level if you are building plugins from user submitted code.
@zacps Maybe something like the above would work for you.
Wouldn't you have to either use code generation or lose type safety though?
@zacps I'm not sure how type safety is related to this...
This all would depend on the user not creating goroutines, but that could be checked for at the source level if you are building plugins from user submitted code.
So using my approach you would write a program to vet the user code before building the plugin. Probably by having a white-list of importable packages, and searching the code to get for invocations of "go X" and any functions in white listed packages you want to also blacklist.
I know it's a finalizer. It is also what the JVM does with JNI code, and the only safe solution I know of without Rust-esque lifetime tracking, generating proxies for each plugin function, or requiring reflection for every invocation.
On Sat, Jun 3, 2017, 9:47 PM Dave Cheney [email protected] wrote:
That's a finaliser.
On Sun, 4 Jun 2017, 11:45 Demi Marie Obenour [email protected] wrote:
What about having the GC close any plugins that are no longer referenced?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-306012057, or mute the thread < https://github.com/notifications/unsubscribe-auth/AAAcAyloFURN5wCFLtkaTGCb3LPug7v7ks5sAgwmgaJpZM4Ni-0b
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/20461#issuecomment-306012133, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWBxUSgkhkS3oeftTUu49MXgnWoeFfks5sAgzNgaJpZM4Ni-0b .
I second starting with an unsafe way to load and unload plugins, with the expectation that the user will sanitize code before compiling it. It's OK if attempting to unload a plugin panics when there exist dangling pointers/references, and it's also OK if the panic happens later nondeterministically when the dangling pointers/references are accessed.
I currently use code generation for templates. I have a template transpiler which transpiles text/template templates to Pure Go (it's a little coupled with my application right now, but I could always split it off and it currently misses a few features).
It would be nice, if I could reload these templates on the fly without restarting the entire instance, something impossible without the ability to close plugins or rolling my own JIT compiler.
Here is a thought: what about having plugins export their API as a first-class object, such that the plugin gets unloaded when the API object is garbage collected?
@DemiMarie this approach is problematic, please see my comments about finalisers earlier in this thread.
Objective C/Swift use automatic reference counting. Maybe that's the approach to take (manual book keeping - but with compiler's assistance)
Indirectly related for some use cases: https://www.datadoghq.com/blog/engineering/cgo-and-python/
This whole thread seems to be discussing a non-issue
To quote the man pages on dlclose(3)
A successful return from dlclose() does not guarantee that the
symbols associated with handle are removed from the caller's address
space. In addition to references resulting from explicit dlopen()
calls, a shared object may have been implicitly loaded (and reference
counted) because of dependencies in other shared objects. Only when
all references have been released can the shared object be removed
from the address space.
So why would we argue about trying to enforce something stronger than the underlying implementation?
Golang has no way to force you to lose your reference to something, nor do I think it should. It is and always has been you (the programmer's) responsibility to not use a resource that you have explicitly asked the system to dispose of.
Its one thing for the app to know it is no longer using references to a plugin that was loaded and think its safe to call dlclose, but what about the runtime, is the GC still going to try to scan that address space and blow up?