Stream: git-wasmtime

Topic: wasmtime / issue #6153 Enabling wasi-threads requires exa...

Wasmtime GitHub notifications bot (Apr 05 2023 at 16:05):

alexcrichton opened issue #6153:

Currently passing --wasi-modules experimental-wasi-threads requires that the input wasm module has a particular "shape", notably that it imports memory and exports a wasi_thread_start function. This ends up making testing sometimes difficult, for example, since ideally the option to the CLI could always be passed and then both threads-using and non-threads-using modules could be run. Or, for example, a module which doesn't end up actually spawning a thread would be run as well.

The current errors are:

$ wasmtime run --wasi-modules experimental-wasi-threads - <<< "(module)"
Error: unable to link a shared memory import to the module; a `wasi-threads` module should import a single shared memory as "memory"
$ wasmtime run --wasm-features threads --wasi-modules experimental-wasi-threads - <<< "(module (import \"env\" \"memory\" (memory 1 2 shared)))"
Error: failed to find wasi-threads entry point function: wasi_thread_start

I think I originally asked these errors in the initial implementation of wasi-threads to be moved to the "front", but now in retrospect I think it would be best to defer these errors to the "point of use" so that way the wasi-threads proposal could be enabled more liberally without restricting the shape of modules that can be run.

cc @abrown

Wasmtime GitHub notifications bot (Apr 05 2023 at 16:05):

alexcrichton labeled issue #6153:

Currently passing --wasi-modules experimental-wasi-threads requires that the input wasm module has a particular "shape", notably that it imports memory and exports a wasi_thread_start function. This ends up making testing sometimes difficult, for example, since ideally the option to the CLI could always be passed and then both threads-using and non-threads-using modules could be run. Or, for example, a module which doesn't end up actually spawning a thread would be run as well.

The current errors are:

$ wasmtime run --wasi-modules experimental-wasi-threads - <<< "(module)"
Error: unable to link a shared memory import to the module; a `wasi-threads` module should import a single shared memory as "memory"
$ wasmtime run --wasm-features threads --wasi-modules experimental-wasi-threads - <<< "(module (import \"env\" \"memory\" (memory 1 2 shared)))"
Error: failed to find wasi-threads entry point function: wasi_thread_start

I think I originally asked these errors in the initial implementation of wasi-threads to be moved to the "front", but now in retrospect I think it would be best to defer these errors to the "point of use" so that way the wasi-threads proposal could be enabled more liberally without restricting the shape of modules that can be run.

cc @abrown

Wasmtime GitHub notifications bot (May 28 2023 at 16:13):

kant2002 commented on issue #6153:

I experience same error when try to run WASM module produced by NativeAOT-LLVM which is experimental toolchain for .NET.

this is simple hello world app which run fine using wasmer but fails to run with wasmtime even if threads was enabled.

> wasmtime  hellowasi.wasm --wasm-features=threads --wasi-modules=experimental-wasi-threads
Error: unable to link a shared memory import to the module;
a `wasi-threads` module should import a single shared memory as "memory"

Below output of wasmer inspect.

> wasmer inspect hellowasi.wasm
Type: wasm
Size: 15.6 MB
Imports:
  Functions:
    "wasi_snapshot_preview1"."args_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."args_sizes_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."environ_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."environ_sizes_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."clock_time_get": [I32, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_advise": [I32, I64, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_close": [I32] -> [I32]
    "wasi_snapshot_preview1"."fd_fdstat_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_fdstat_set_flags": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_filestat_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_filestat_set_size": [I32, I64] -> [I32]
    "wasi_snapshot_preview1"."fd_pread": [I32, I32, I32, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_prestat_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_prestat_dir_name": [I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_pwrite": [I32, I32, I32, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_read": [I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_readdir": [I32, I32, I32, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_seek": [I32, I64, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_sync": [I32] -> [I32]
    "wasi_snapshot_preview1"."fd_write": [I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."path_create_directory": [I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."path_filestat_get": [I32, I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."path_open": [I32, I32, I32, I32, I32, I64, I64, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."path_readlink": [I32, I32, I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."path_unlink_file": [I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."poll_oneoff": [I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."proc_exit": [I32] -> []
    "wasi_snapshot_preview1"."sched_yield": [] -> [I32]
    "wasi_snapshot_preview1"."random_get": [I32, I32] -> [I32]
    "wasi"."thread-spawn": [I32] -> [I32]
  Memories:
  Tables:
  Globals:
Exports:
  Functions:
    "_start": [] -> []
    "wasi_thread_start": [I32, I32] -> []
  Memories:
    "memory": shared (19 pages..32768 pages)
  Tables:
  Globals:

I see memory with "memory" name, so whole thing a bit puzzling to me. I assume that wasi-threads also define memory, so there collision between two of them. But really I don't know, since I'm new to all this jazz.

Wasmtime GitHub notifications bot (May 28 2023 at 17:51):

bjorn3 commented on issue #6153:

Wasi requires exporting a memory (so the wasi runtime can write to memory), while wasi-threads requires importing it (so that it is possible to share the same memory between the wasm instances backing each thread). As such you need to tell the linker to import a linear memory and re-export the same linear memory.

Wasmtime GitHub notifications bot (May 28 2023 at 18:06):

kant2002 commented on issue #6153:

@bjorn3 thank you! it indeed helps, and your explanation make sense. I'm not sure will it hijack thread from original issue of OP, but is it possible that wasmtime detect such simple errors and provide slightly better messaging?

Wasmtime GitHub notifications bot (May 28 2023 at 18:14):

bjorn3 commented on issue #6153:

A hint on how to fix the issue would be nice IMHO.

Wasmtime GitHub notifications bot (Jun 01 2023 at 16:02):

alexcrichton closed issue #6153:

Currently passing --wasi-modules experimental-wasi-threads requires that the input wasm module has a particular "shape", notably that it imports memory and exports a wasi_thread_start function. This ends up making testing sometimes difficult, for example, since ideally the option to the CLI could always be passed and then both threads-using and non-threads-using modules could be run. Or, for example, a module which doesn't end up actually spawning a thread would be run as well.

The current errors are:

$ wasmtime run --wasi-modules experimental-wasi-threads - <<< "(module)"
Error: unable to link a shared memory import to the module; a `wasi-threads` module should import a single shared memory as "memory"
$ wasmtime run --wasm-features threads --wasi-modules experimental-wasi-threads - <<< "(module (import \"env\" \"memory\" (memory 1 2 shared)))"
Error: failed to find wasi-threads entry point function: wasi_thread_start

I think I originally asked these errors in the initial implementation of wasi-threads to be moved to the "front", but now in retrospect I think it would be best to defer these errors to the "point of use" so that way the wasi-threads proposal could be enabled more liberally without restricting the shape of modules that can be run.

cc @abrown

Wasmtime GitHub notifications bot (Jun 01 2023 at 16:02):

alexcrichton closed issue #6153:

Currently passing --wasi-modules experimental-wasi-threads requires that the input wasm module has a particular "shape", notably that it imports memory and exports a wasi_thread_start function. This ends up making testing sometimes difficult, for example, since ideally the option to the CLI could always be passed and then both threads-using and non-threads-using modules could be run. Or, for example, a module which doesn't end up actually spawning a thread would be run as well.

The current errors are:

$ wasmtime run --wasi-modules experimental-wasi-threads - <<< "(module)"
Error: unable to link a shared memory import to the module; a `wasi-threads` module should import a single shared memory as "memory"
$ wasmtime run --wasm-features threads --wasi-modules experimental-wasi-threads - <<< "(module (import \"env\" \"memory\" (memory 1 2 shared)))"
Error: failed to find wasi-threads entry point function: wasi_thread_start

I think I originally asked these errors in the initial implementation of wasi-threads to be moved to the "front", but now in retrospect I think it would be best to defer these errors to the "point of use" so that way the wasi-threads proposal could be enabled more liberally without restricting the shape of modules that can be run.

cc @abrown

Last updated: Dec 23 2024 at 12:05 UTC