Stream: git-wasmtime

Topic: wasmtime / issue #7258 wasi-streams for stdio: Spawned wo...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 16 2023 at 18:10):

pchickey edited issue #7258:

Currently the worker thread managing writes to stdout will drop when the guest-side write end is dropped. We need to fix this, as it's quite common to repeatedly call std::io::get_stdout() and drop the result in rust.

The general approach that we discussed is to have the stdout/stderr worker tasks alive for the duration of the guest, and a separate channel for reporting new write channels to those tasks. The tasks would then be responsible for selecting between the new writer channel and all the known writer channels when processing incoming jobs, removing known writers from the managed set when those ends drop instead of aborting.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 25 2023 at 22:36):

alexcrichton commented on issue #7258:

@pchickey question for you, do you remember why we have it such that stdout/stderr perform async writes? Was that made as a specific design choice or rather "well everything is async so may as well"?

If the latter I might actually propose solving this issue by "just" doing a blocking write to stdout/stderr. I feel like I'm forgetting something though because I suspect we would have tried to talk about this when figuring out flushing and such. What I'm thinking is basically the implementation of LogStream from @elliottt's current PR is what we'd bake in as the default stdout/stderr (minus the addition of prefixes per request).

view this post on Zulip Wasmtime GitHub notifications bot (Nov 01 2023 at 01:04):

elliottt closed issue #7258:

Currently the worker thread managing writes to stdout will drop when the guest-side write end is dropped. We need to fix this, as it's quite common to repeatedly call std::io::get_stdout() and drop the result in rust.

The general approach that we discussed is to have the stdout/stderr worker tasks alive for the duration of the guest, and a separate channel for reporting new write channels to those tasks. The tasks would then be responsible for selecting between the new writer channel and all the known writer channels when processing incoming jobs, removing known writers from the managed set when those ends drop instead of aborting.


Last updated: Nov 22 2024 at 17:03 UTC