P3 stdout implementation

[cpetig]

This needed a bit more of file infrastructure than I anticipated. The code in wasip3_file_utils.c needs more work to set the proper errno when writes/reads fail, but for stdout/in it should be good for a first step.

[alexcrichton]

Thanks for this! I'll caution that the test coverage of this repository is very light so I'm going to try to pick these apart in terms of review to try to make them as correct as I can think. In that sense it might be good to expand the test suite over time, but what I'm talking about may also be covered by other tests over time as they get enabled, unsure.

One high-level point though is that reads/writes of streams don't have a default way to communicate an error if you're working with just the stream. Conventionally in wasip3 this means that the error information is always a side-channel of sorts via a future or a task or something like that. Whenever a read or write indicates that the stream is closed we'll want to then block waiting on the resolution of the subtask in question. That'll carry error information with it and indicate if the prior read failed, why it failed, etc.

I'm not sure how best to organize this in wasi-libc in terms of whether we want all this in read.c/write.c, most of it in a helper, or what. I do think a lot of this is going to want to be shared with pipes/tcp eventually so we'll want to keep that in mind to ensure that there's minimal duplication across these files.

[cpetig]

Thanks for this! I'll caution that the test coverage of this repository is very light so I'm going to try to pick these apart in terms of review to try to make them as correct as I can think. In that sense it might be good to expand the test suite over time, but what I'm talking about may also be covered by other tests over time as they get enabled, unsure.

I support the thankless task to keep high quality standards on open source, even though it clearly means more (early) work for me within this MR!

I will implement my idea for proper error handling to files (there should a proper check on a file API test) on this MR, but it might take me some days. Similarly for factoring code out of read+write.

Thanks for all your work!

[alexcrichton]

I've got some minor comments below but I think overall this has turned out great, thanks again for working on this!

I'd be happy to merge as-is to help unblock further work (e.g. on filesystems). I'm also happy to try to address some of the follow-ups in future PRs myself to. Just let me know which you'd prefer.

[cpetig]

I've got some minor comments below but I think overall this has turned out great, thanks again for working on this!

I'd be happy to merge as-is to help unblock further work (e.g. on filesystems). I'm also happy to try to address some of the follow-ups in future PRs myself to. Just let me know which you'd prefer.

These are good suggestions, all are now implemented.

[cpetig]

by the way: I found that zero size reads/writes block, because they confuse it with eof/error, already fixed on the file PR

Easily cherry-picked.

[alexcrichton]

Thanks! I think we may end up needing to refine 0-length reads/writes further in the sense that my recollections is they don't block on POSIX but they are blocking in the component model, so there might need to be an early return too eventually.

Nevertheless it's fine to defer that to later and any behavior changes there can be accompanied with tests too.