Recent searches
Search options
A counter-intuitive thing about coroutine-style streams from a channel perspective is that write errors, eg. "filesystem out of space" or "network disconnected" etc., aren't natural to report to writers.
My channel intuition thinks "of course writers need to know if writes fail".
But in coroutine-style streams, the caller of a writer is the thing that's consuming the output. If it has an error, it will report the error back to its caller, rather than needing the writer to do it.
In terms of the call tree, a Unix pipeline `a | b | c` looks like this:
```
a() b() c()
↑ ↑ ↑
--shell--
```
With coroutine-style streams, the call tree for such a pipeline
would look like this:
```
a()
↑
b()
↑
c()
↑
shell
```
The other difference is that in typical Unix pipeline scenarios, the outputs of a pipeline are something like terminals or files or sockets, which is to say, something in the OS. The OS isn't in the call tree, and can't "return" and report a failure to its "caller". So it needs to push the error back upstream to the last writer, which can then fail to its caller (the shell).
In coroutine style, the last writer is just returning results. If you want to store those results in a file, you can call a function and pass it the resulting stream and filesystem resources to store the data to. But in that case, if a failure happens, that function can report the error to its caller.
@sunfish Is this in the context of some WA/WASI proposal or just a general observation?
@zwarich It's a general observation, though WASI is what's motivating it.
There's no official proposal yet, but I expect WASI Preview 3 streams will be coroutine-style. It would fix some of the major limitations of Preview 2 streams.