Stream: git-wasmtime

Topic: wasmtime / PR #11406 feat(wasip3): implement `wasi:filesy...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2025 at 17:49):

rvolosatovs opened PR #11406 from rvolosatovs:feat/wasip3-filesystem to bytecodealliance:main:

Refs https://github.com/bytecodealliance/wasip3-prototyping/issues/228

Looks like reads will benefit from quite a bit of refactoring, which I did not manage to get to this week yet.
Keeping this open as draft for now until that's done.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2025 at 17:49):

rvolosatovs edited PR #11406:

Refs https://github.com/bytecodealliance/wasip3-prototyping/issues/228

Looks like reads will benefit from quite a bit of refactoring, which I did not manage to get to this week yet.
Keeping this open as draft for now until that's done (I'll get back to it next week)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2025 at 17:55):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2025 at 17:56):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2025 at 18:01):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 09 2025 at 01:08):

alexcrichton created PR review comment:

Similar to above, mind filing an issue for this? (unless the intention is to fill out in this PR)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 09 2025 at 01:08):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 09 2025 at 01:08):

alexcrichton created PR review comment:

Is this a difference from WASIp3 intentionally? Or just an artifact of a test doing two invalid things at once and which error is coming out is now different?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 09 2025 at 01:08):

alexcrichton created PR review comment:

mind filing an issue for this if the intention is to leave this before landing?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 09 2025 at 01:08):

alexcrichton created PR review comment:

Where it makes sense for types like this I think it'd also be reasonable to use the cap-std types directly and avoid having a layer of abstraction which is wasmtime-wasi specific (e.g. directly convert bindgen-generated types to cap-std types).

I don't think it makes sense for all types, but for some like this it might be reasonable to skip the extra enum here.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:34):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:34):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:34):

rvolosatovs created PR review comment:

I've tried to preserve existing behavior as much as possible originally, but have since changed that and documented in https://github.com/bytecodealliance/wasmtime/pull/11406/commits/0418f5432d93be38dad8f8dd71926a911b3a8933

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:37):

rvolosatovs commented on PR #11406:

Unfortunately, I'm running into a runtime panic in https://github.com/bytecodealliance/wasmtime/pull/11406/commits/54384721d13fcf5eecdc11a57eeb2c2a1c3e73c9:

thread 'p3::p3_filesystem_file_read_write' panicked at crates/wasmtime/src/runtime/component/concurrent/tls.rs:81:5:
attempted to recursively call `tls::get` when the pointer was not present or already taken by a previous call to `tls::get`

I've ignored the test for now https://github.com/bytecodealliance/wasmtime/pull/11406/commits/f8dc7e0c088178b3346bab261e2f73720944f29c and will file an issue in a bit

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:40):

rvolosatovs edited PR #11406:

Refs https://github.com/bytecodealliance/wasip3-prototyping/issues/228

~Looks like reads will benefit from quite a bit of refactoring, which I did not manage to get to this week yet.
Keeping this open as draft for now until that's done (I'll get back to it next week)~

Unlike https://github.com/bytecodealliance/wasip3-prototyping, read tasks both for wasi:sockets and wasi:filesystem are "orphaned", i.e. there's no parent-child relationship enforcement and therefore reads may continue after the resource the read was called on is dropped. For example, currently guests can continue reading from a file after dropping it.

I'm planning to enforce the parent-child relationship for both wasi:sockets and wasi:filesystem in a follow-up, which would be done in a similar way to wasi:http https://github.com/WebAssembly/wasi-http/blob/ad500ba30bdfd57e04bdabdcd0480111681bf017/wit-0.3.0-draft/types.wit#L420-L423

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:45):

rvolosatovs edited a comment on PR #11406:

Unfortunately, I'm running into a runtime panic in https://github.com/bytecodealliance/wasmtime/pull/11406/commits/54384721d13fcf5eecdc11a57eeb2c2a1c3e73c9:

thread 'p3::p3_filesystem_file_read_write' panicked at crates/wasmtime/src/runtime/component/concurrent/tls.rs:81:5:
attempted to recursively call `tls::get` when the pointer was not present or already taken by a previous call to `tls::get`

I've ignored the test for now https://github.com/bytecodealliance/wasmtime/pull/11406/commits/f8dc7e0c088178b3346bab261e2f73720944f29c and ~will file an issue in a bit~ filed and issue: https://github.com/bytecodealliance/wasmtime/issues/11412

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:46):

rvolosatovs has marked PR #11406 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:46):

rvolosatovs requested wasmtime-wasi-reviewers for a review on PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:46):

rvolosatovs requested dicej for a review on PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:46):

rvolosatovs requested wasmtime-core-reviewers for a review on PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 11:46):

rvolosatovs requested wasmtime-default-reviewers for a review on PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:41):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:41):

rvolosatovs edited PR #11406:

Refs https://github.com/bytecodealliance/wasip3-prototyping/issues/228

~Looks like reads will benefit from quite a bit of refactoring, which I did not manage to get to this week yet.
Keeping this open as draft for now until that's done (I'll get back to it next week)~

~Unlike https://github.com/bytecodealliance/wasip3-prototyping, read tasks both for wasi:sockets and wasi:filesystem are "orphaned", i.e. there's no parent-child relationship enforcement and therefore reads may continue after the resource the read was called on is dropped. For example, currently guests can continue reading from a file after dropping it. ~

~I'm planning to enforce the parent-child relationship for both wasi:sockets and wasi:filesystem in a follow-up, which would be done in a similar way to wasi:http https://github.com/WebAssembly/wasi-http/blob/ad500ba30bdfd57e04bdabdcd0480111681bf017/wit-0.3.0-draft/types.wit#L420-L423~

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:42):

rvolosatovs edited PR #11406:

Refs https://github.com/bytecodealliance/wasip3-prototyping/issues/228

~Looks like reads will benefit from quite a bit of refactoring, which I did not manage to get to this week yet.
Keeping this open as draft for now until that's done (I'll get back to it next week)~

~Unlike https://github.com/bytecodealliance/wasip3-prototyping, read tasks both for wasi:sockets and wasi:filesystem are "orphaned", i.e. there's no parent-child relationship enforcement and therefore reads may continue after the resource the read was called on is dropped. For example, currently guests can continue reading from a file after dropping it.~

~I'm planning to enforce the parent-child relationship for both wasi:sockets and wasi:filesystem in a follow-up, which would be done in a similar way to wasi:http https://github.com/WebAssembly/wasi-http/blob/ad500ba30bdfd57e04bdabdcd0480111681bf017/wit-0.3.0-draft/types.wit#L420-L423~

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:45):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:46):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 12:49):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 14:32):

alexcrichton submitted PR review:

I'll take a look at this panic

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 14:32):

alexcrichton created PR review comment:

Was this necessary to pass tests? Ideally I'd like to avoid abstractions like this and as-is I'm not sure that this is doing much because a strong reference to the TaskTable is held in all subtasks meaning that it'll never get dropped until the file is already dropped otherwise. For filesystems this is also problematic because aborting a task does not guarantee its destruction, you'd still have to await the handle in some form (we don't support this right now) due to the fact that the other task still needs to be dropped. For filesystem things that's also hard because it can often involve a spawn_blocking which itself contains a strong reference to the file in question and isn't cancellable once it's started.

More-or-less my hypothesis is that this isn't doing anything right now other than adding overhead for task-tracking because it's only dropped when a file is already being dropped. Otherwise I'm not sure we're prepared to give such a guarantee for filesystems that the host descriptor is closed once the WASI descriptor is closed.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 15:08):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 15:08):

rvolosatovs created PR review comment:

The drop of a descriptor explicitly makes sure to "drain" the task table https://github.com/bytecodealliance/wasmtime/pull/11406/files#diff-0e2974d9a17b9ade0679e01bc627e119e1956a7bc903a9f10530f10b5865c2cfR621

I'm happy to drop https://github.com/bytecodealliance/wasmtime/pull/11406/commits/40415b52f79a33c376a2a875ffecb1d0a01c7903 though and perhaps talk through this later today?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 15:09):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 15:09):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 17:07):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 11 2025 at 17:09):

rvolosatovs commented on PR #11406:

@alexcrichton this should be ready for a repeated review now

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:15):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:20):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:23):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:41):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:48):

rvolosatovs updated PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 07:56):

rvolosatovs has enabled auto merge for PR #11406.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 12 2025 at 08:30):

rvolosatovs merged PR #11406.

Last updated: Dec 06 2025 at 06:05 UTC