YAMAMOTO Takashi

> But, are you suggesting that removing read/write bits based on the access mode is acceptable according to STDXX? yes. i think it's the most straightforward behavior. what's your concern?

@lum1n0us can we decide on this? (and/or https://github.com/bytecodealliance/wasm-micro-runtime/pull/4395) or, do you have some more info? (eg. need a research on something)

> The main concern is that after this modification, the code below will allow STDIN to be unreadable and STDOUT to be unwritable in some scenarios, which I don't think...

maybe it's caused by the runner image upgrade? (windows-2022 -> windows-2025)

> [#4256](https://github.com/bytecodealliance/wasm-micro-runtime/issues/4256) oh, was it this May? i thought it was at least a few years ago. it seems my memory is severely broken.

> You are right. The current design doesn't accommodate usage scenarios like varying WASI contexts for multiple instances (either continuously in one thread or parallelly across multiple threads) of a...

i feel it's an abuse for a runtime to change its behavior on target_features. when we couldn't load a module, we might be able to provide a bit more useful...

> (and probably deprecate wasi_nn and remove it in future.) wasi_ephemeral_nn support was introduced by: ``` commit db025e457afd3846815e34b385ecd79bc3262f8d Author: liang.he Date: Mon Jun 17 14:58:09 2024 +0800 ``` and has...

wasi_ephemeral_nn is now the default. build-time deprecation warning has been added too.

as wasm_propagate_wasi_args is only called by wasm_runtime_set_wasi_args and iwasm happens to call wasm_runtime_set_wasi_args before wasm_runtime_set_wasi_addr_pool/wasm_runtime_set_wasi_ns_lookup_pool, those settings are not propagated. having said that, wasm_propagate_wasi_args is a misfeature, IMO. for multi...