-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support deinstantiation (mod.Close) #293
Comments
This would also be needed for wapc-go (cc @pkedy) because it is otherwise a memory leak. For example, modules are instantiated with instance counters, which I assume would eventually run out of memory depending on the scope and frequency of creation (remember memory is required by WASI and minimum memory is 64KB).
|
There's a not really documented thing in AssemblyScript that would also needs this for abort handling. If someone can find docs on it please do! // envAbort is the AssemblyScript abort handler.
// Ex in WebAssembly 1.0 (MVP) Text Format:
// (import "env" "abort" (func $~lib/builtins/abort (param i32 i32 i32 i32)))
func (t *thing) envAbort(ctx wasm.ModuleContext, messageOffset, fileOffset, line, col uint32) {
t.module.Close()
} Note: AssemblyScript maybe maps this function to WASI sigabrt ... |
yeah we also tweak Engine interface so that we can unmap the MMapped memory regions |
This commit refactors store.go and adds store.ReleaseModuleInstance. Notably, this removes the "rollback" functions in InstantiateModule which we had used to rollback the mutated state when we encounter the initialization failure. Instead, we separate out the validation from initialization and migrate most of the validation logics into module.go As for ReleaseModuleInstance, that is necessary to complete #293, will be leveraged to make it possible for store to be used for long-running processes and environment. Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
so the preliminary work #294 has just landed, so the next is to make store goroutine-safe |
This commit adds Module.Close API, which can be used to indicate that the module will no longer be used and setting finalizers for the allocated resources. Notably, this will set finalizers on compiledFunction to deallocate mapped memory regions as well as removing them from the store-wide storage. As a result, users can re-instantiate a module for the same name while having the safety -- Calling Module.Close is safe even when there are outstanding function calls as we never explicitly deallocate but indirectly do that via Goruntine's finalizers. resolves: #293 Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
We need to eventually handle long lived processes, and graceful shutdown. If we had a way to deinstantiate a module, I think we can also handle a WASI quit signal scoped to module instead of the host process (#290)
I think we should make a new type that implements ModuleExports called
wazero.InstantiatedModule
(we maybe need this for host also, but let's start with normal modules). The only additional function there would be .Close and this would have the following effects.closeCalled
CancelContext
added to the callEngine, and invoke that hook so that any host functions doing I/O finish.wazero.StartWASICommand
as maybe non-wasi shouldn't be doing I/O anywayThe text was updated successfully, but these errors were encountered: