Skip to content
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

__wasm_call_dtors for reactors #593

Open
SBKarr opened this issue Apr 2, 2024 · 1 comment
Open

__wasm_call_dtors for reactors #593

SBKarr opened this issue Apr 2, 2024 · 1 comment

Comments

@SBKarr
Copy link

SBKarr commented Apr 2, 2024

Example usage model:

  • Host app instantiates module, run _initialize/__wasm_call_dtors
  • Calls some functions
  • Closes the module, run /__wasm_call_dtors to release resources correctly

In current model, commands should not preserve state, it's one-call entities

Reactors can be initialised then called multiple times, but it's rely on root command for destructors. If we define dtors in reactor itself, it can broke command, that uses it.

For now, clang from wasi-sdk-21 (Rust too?) do not emits destructors code for reactor at all, only registers with __cxa_atexit. There should be a way to deinstantiate that type of module correctly. Maybe, some compiler flag on another exec model?

Upd: Ok, if i define some function, that calls __wasm_call_dtors directly, with -mexec-model=reactor it works as expected. Is it well-defined behavior? lld do not checks, that function is somehow exported, and can just strip it with '-Os', but leave __wasm_call_dtors in place.

@sunfishcode
Copy link
Member

What kinds of cleanups does your code need to do? In some contexts, reactors are terminated abruptly by simply exiting the host process, which wouldn't give the Wasm code a chance to run any destructors. And if Wasm code traps, then it wouldn't be safe to re-enter it to call destructors for cleanups.

In WASIp2 with the component model, resources can have destructors that can automatically clean up external resources associated with handles, and that lets us clean up even in the case of abrupt exits such as traps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants