YAMAMOTO Takashi

@no1wudi any idea?

> Speed of "sequential" test seems acceptable: #3780 > > Maybe we can try it fist > > @wenyongh @lum1n0us @yamt it's still failing. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/10775274630/job/29879549182

> How about re-opening #3777 and merging it? re-opened and rebased.

> It's more like an issue related to riscv32_ilp32f, the CI ran failed most on config "riscv32_ilp32f, fp, -t aot -X" and "riscv32_ilp32f, fp, -t aot": https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/10775274630/job/29906929175#step:25:7726 https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/10775274630/job/29906623580 https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/10783438239/job/29906934331 https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/10783852668/job/29906610576...

the following functions seem to lack necessary address validation. sock_accept sock_addr_resolve sock_bind sock_connect sock_open sock_recv_from sock_recv sock_send sock_send_to

wamr is not cancellation safe. use wasm_runtime_terminate to terminate the instance instead.

the underlying api (os_wakeup_blocking_op etc) is not implemented for all platforms. zephyr doesn't seem to have it.

the tricky part is that it needs to somehow cancel host functions like WASI. for unix-like platforms it's implemented using signals as signals can interrupt most of blocking system calls...

i guess you should explain the motivation of auto-detection.

> > i guess you should explain the motivation of auto-detection. > > The motivation is to implement auto-detect option in encoding when loading a model file. In case a...