Is it safe to have two exec_envs at the same time?

[NinevskiyK]

Let's assume we have native, and two wasm modules: main and worker. Native is calling main module, and exporting native function call_worker to it. Main module calls call_worker function, which is calling(call_worker is native's function) worker wasm module, and passes worker return to the main.

The only problem here is with exec_env_tls - when I'm creating second exec_env for worker, exec_env_tls is already set(when creating main), which is causing invalid exec env exception. I've commented this check, and everything works perfectly fine.

Why do we need this strange variable? I've only found that it is used to handle signals, but if I'm not aiming to signal wasm modules, will it affect somehow in another way?

[wenyongh]

Hi, using exec_env_tls is due to using hardware trap to implement boundary check of linear memory access:
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/build_wamr.md#disable-boundary-check-with-hardware-trap
Since when out of bounds memory access occurs, the signal handler will be triggered to handle it, and inside the signal handler, there is no good way to know the exec_env of current thread, we store it into thread local storage to retrieve it quickly.

Maybe you can temporarily save the exec_env_tls before calling worker wasm module, and restore it after calling:

#include "core/iwasm/common/wasm_runtime_common.h"
call_worker ()
{
    exec_env_backup = wasm_runtime_get_exec_env_tls();
    wasm_runtime_set_exec_env_tls(NULL);
    call worker wasm module
    wasm_runtime_set_exec_env_tls(exec_env_backup );
}

[NinevskiyK]

Perfect, this is working and makes sense, thanks!