Stream: git-wasmtime

Topic: wasmtime / PR #11615 wasip3: Refactor the readdir stream ...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 03:11):

alexcrichton requested rvolosatovs for a review on PR #11615.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 03:11):

alexcrichton opened PR #11615 from alexcrichton:wasip3-refactor-readdir-iterator to bytecodealliance:main:

Follow-up from https://github.com/bytecodealliance/wasmtime/pull/11515, part stylistic part tweaking behavior. Includes a test now too!

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 03:11):

alexcrichton requested wasmtime-wasi-reviewers for a review on PR #11615.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 03:11):

alexcrichton requested fitzgen for a review on PR #11615.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 03:11):

alexcrichton requested wasmtime-core-reviewers for a review on PR #11615.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 06:42):

rvolosatovs created PR review comment:

In p2 this operation is performed in a separate thread (if runtime is configured to do so), so I assumed this may run for a while and avoided calling it from within read_directory. Since read_directory is not marked async, I think the expectation is that it should return as soon as possible, hence why IMO entries() should only be called after stream.read.

Of course, if cost of calling entries is negligible that does not matter. Are we sure this function will not block for long?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 06:42):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 06:42):

rvolosatovs created PR review comment:

        // Drain `self.iter`. Successful results go into `buf`. Any errors make

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 06:42):

rvolosatovs created PR review comment:

Is this correct? I was under impression that a stream.read can be cancelled, but that does not cancel the underlying stream itself

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 14:23):

alexcrichton created PR review comment:

You're correct about the consequences, yeah, but this is within the allow_blocking_current_thread block, so the blocking is intentional. Given that I think this is the same as p2?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 14:23):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 14:23):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 14:23):

alexcrichton created PR review comment:

You're right yeah, I keep confusing myself about how to handle finish.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 14:25):

alexcrichton updated PR #11615.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 15:06):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 15:06):

rvolosatovs created PR review comment:

I've probably only noticed this, because I've done the exact same thing :sweat_smile:

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

rvolosatovs submitted PR review.

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

rvolosatovs created PR review comment:

Yes, you're right, looks good!

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

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 05 2025 at 15:32):

rvolosatovs merged PR #11615.

Last updated: Dec 06 2025 at 06:05 UTC