YAMAMOTO Takashi

Results 115 issues of YAMAMOTO Takashi

in posix, `openat(dirfd, "../b", ...)` should work. however, in wasi, O_RESOLVE_BENEATH behavior is unconditionally applied. (at least in popular implementations. i don't know if it was well documented for preview1....

in make_absolute: - __wasilibc_cwd_unlock is called twice - static vars (make_absolute_buf/make_absolute_len) are used w/o lock in chdir: - static vars (relative_buf/relative_buf_len/__wasilibc_cwd_mallocd) are used w/o lock

Note: a return from main() is an equivalent of exit(), which should terminate sibling threads.

cf. https://github.com/WebAssembly/wasi-threads/pull/26

https://github.com/WebAssembly/wasi-threads/issues/7 https://github.com/WebAssembly/wasi-threads/pull/17

tensor-data is `list`. but i suppose that its actual contents are eg. f32. does wit/interface-types/etc provide a large enough alignment?

my understanding is * wit version and witx version of the interface are not API/ABI compatible * the only implemention of the wit version is https://github.com/fermyon/wasi-experimental-toolkit/tree/main/crates/nn-tract-wasmtime am i right?

the description of `wasi_thread_spawn` says: ``` instantiate the module again — this child instance will be used for the new thread ``` it isn't obvious to me which module "the...

currently it's just said: ``` When instantiating a module which is expected to run with `wasi-threads`, the WASI host must first allocate shared memories to satisfy the module's imports. ```...

* there seems to be a consensus memory should be imported for wasi-threads. clarification: https://github.com/WebAssembly/wasi-threads/pull/20 * on the other hand, it's said that memory should be exported in wasi: https://github.com/WebAssembly/WASI/blob/main/legacy/application-abi.md#current-unstable-abi...