Stream: git-wasmtime

Topic: wasmtime / issue #8894 `wasi-common`: Does `sync` crate f...

Wasmtime GitHub notifications bot (Jul 02 2024 at 09:10):

Robbepop opened issue #8894:

I am writing this issue since I think it is the better place to ask than my question at Zulip.

I was looking at wasi-common's sync crate feature and it seems to be depending on wasmtime as dependency.

I found this to be weird and checked out the repositoy locally and just removed the feature dependency line in the Cargo.toml after not really seeing any real dependency on Wasmtime in the sync specific code at first glace. Everything still compiled with cargo build -p wasi-common --no-default-features --features sync.

Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use wasi-common with its sync feature to enable WASI and drop the heavily outdated wasi-cap-std-sync crate entirely.

Wasmtime GitHub notifications bot (Jul 02 2024 at 09:11):

Robbepop edited issue #8894:

I am writing this issue since I think it is the better place to ask than my question at Zulip.

I was looking at wasi-common's sync crate feature and it seems to be depending on wasmtime as dependency.

I found this to be weird and checked out the repository locally and just removed the feature dependency line in the Cargo.toml after not really seeing any real dependency on Wasmtime in the sync specific code at first glace. Everything still compiled with cargo build -p wasi-common --no-default-features --features sync.

Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use wasi-common with its sync feature to enable WASI and drop the heavily outdated wasi-cap-std-sync crate entirely.

Wasmtime GitHub notifications bot (Jul 02 2024 at 09:13):

Robbepop edited issue #8894:

I am writing this issue since I think it is the better place to ask than my question at Zulip.

I was looking at wasi-common's sync crate feature and it seems to be depending on wasmtime as dependency.

I found this to be weird and checked out the repository locally and just removed the feature dependency line in the Cargo.toml after not really seeing any real dependency on Wasmtime in the sync specific code at first glace. Everything still compiled with cargo build -p wasi-common --no-default-features --features sync.

Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use wasi-common with its sync feature to enable WASI and drop the heavily outdated wasi-cap-std-sync crate entirely.

This is especially important for Wasmi since for technical reasons Wasmi has to use the super outdated v2.0.0 of wasi-cap-std-sync crate and dependabot recently turned my attention to a security issue with atty that is used by wasi-cap-std-sync version v2.0.0.

Wasmtime GitHub notifications bot (Jul 08 2024 at 13:56):

alexcrichton closed issue #8894:

I am writing this issue since I think it is the better place to ask than my question at Zulip.

I was looking at wasi-common's sync crate feature and it seems to be depending on wasmtime as dependency.

I found this to be weird and checked out the repository locally and just removed the feature dependency line in the Cargo.toml after not really seeing any real dependency on Wasmtime in the sync specific code at first glace. Everything still compiled with cargo build -p wasi-common --no-default-features --features sync.

Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use wasi-common with its sync feature to enable WASI and drop the heavily outdated wasi-cap-std-sync crate entirely.

This is especially important for Wasmi since for technical reasons Wasmi has to use the super outdated v2.0.0 of wasi-cap-std-sync crate and dependabot recently turned my attention to a security issue with atty that is used by wasi-cap-std-sync version v2.0.0.

Last updated: Dec 06 2025 at 06:05 UTC