Enable aux stack allocations on application heap#1799
Enable aux stack allocations on application heap#1799wenyongh merged 3 commits intobytecodealliance:dev/wasi_threadsfrom
Conversation
4004fee to
b2cb12b
Compare
|
|
||
| /* routine exit, destroy instance */ | ||
| wasm_runtime_deinstantiate_internal(module_inst, true); | ||
|
|
There was a problem hiding this comment.
how is this related to the rest of the PR?
There was a problem hiding this comment.
If WASM_ENABLE_HEAP_AUX_STACK_ALLOCATION is enabled, module instance can't be deinstantiate untill the memory allocated for the aux stack is released.
There was a problem hiding this comment.
- with this change, where will it be deinstantiated instead?
- how about the other wasm_runtime_deinstantiate_internal call in this function? (L507)
There was a problem hiding this comment.
with this change, where will it be deinstantiated instead?
It's deinstantiated in the thread_manager_start_routine()
how about the other wasm_runtime_deinstantiate_internal call in this function? (L507)
Yes, this one, and one in the lib_wasi_threads_wrapper.c have to be removed. Already updated the code, thanks.
There was a problem hiding this comment.
do you mean already updated locally but not pushed yet?
There was a problem hiding this comment.
Yes sorry, didn't push my change. Should be updated now.
The refactoring is necessary for further steps where we use module instance of the exec env environment to perform on-heap aux stack allocations.
This enables us to have fully application-managed aux stack. The change is needed for wasi threads where aux stack is managed by Libc.
b2cb12b to
762b501
Compare
So it can be used in thread manager even if wasi threads aren't enabled.
762b501 to
c344759
Compare
This is necessary for WASI threads as the aux stack should be managed by the application. See bytecodealliance#1790 for details.
This is necessary for WASI threads as the aux stack should be managed by the application. See #1790 for details.