wasm_c_api, its thread model and disabling the hardware bound check

[schorg]

I am using the wasm_c_api to create a Wasm host in a real-time scheduler and run exported functions of a reactor guest from the scheduler.

The realtime scheduler has a non-realtime initialization phase where I create the wasm_store_t and all its objects.
Then the realtime scheduler can be switched to its operating phase where the exported functions of the reactor guest are called in realtime (periodically or event-driven).

According to the wasm_c_api documentation, the wasm_store_t and all its objects need to be accessed from the same thread.

Unfortunately, the real-time scheduler uses different threads in the non-realtime initialization phase and in the realtime operating phase. This creates an error because the wasm_runtime uses thread local storage for it's implementation.
The source code shows, that thread-local storage is only needed for the hardware bound check.

Disabling the hardware bound check

set (WAMR_DISABLE_HW_BOUND_CHECK 1)

enables to initialize the runtime and call the exported functions from different threads. Everything works fine.

Now my questions:

1. What are the consequences of disabling the hardware bound check for the Wasm reactor guest ?
2. Is there a simple way to initialize the wasm_store and all its objects and calling the exported functions from different threads, without disabling the hardware bound check ?

Thanks for any hints and explanations.

FJG

[schorg]

Found an answer to 1. myself in the documentation.
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/build_wamr.md#disable-boundary-check-with-hardware-trap

[schorg]

Concerning 2.

I understand the problem is related to discussion #2381
From the answer #2381 (comment) I understand the exec_env is stored in thread local storage.

I suspect my setup would work if storing the exec_env in thread local storage would be delayed until the first call of an exported function from the realtime thread.

Is this an option?