fix(c-api) Don't drain the entire captured stream at first read #2070
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We use
VecDeque::drain
to read the captured stream, zipped with thegiven buffer. We could expect that only the yielded items from the
drain
will be removed, but actually no. Reading thedocumentation:
So by using a range like
..
(as we do) will drain the entire captured stream,whatever we read from it. Said differently, if the given buffer length
is smaller than the captured stream, the first read will drain the
entire captured stream.
This patch fixes the problem by specifying a better range:
..min(inner_buffer.len(), oc.buffer.len())
.With this new range, it's actually useless to increment
num_bytes_written
, we already know ahead of time the amount of byteswe are going to read. Consequently, the patch simplifies this code a
little bit more.
This patch also updates the
test-wasi
integration test. Previously,stdout
wasn't captured, so the loop usingwasi_env_read_stdout
wasdoing nothing. Now we have the following output:
Review