Wasip3: poll implementation

[cpetig]

Without the separate file nor stream support this doesn't change any test to work, yet. (The code worked for me with tcp in the past, though)

[cpetig]

Another part of #711

[alexcrichton]

This is definitely going to be a particularly tricky one to implement. The main thing is that the component model doesn't specify that a 0-length read/write is guaranteed to signal readiness, so wasi-libc will need to recover in situations where readiness isn't working. That'll involve storing a bit more state in the fds in wasi-libc for handles and is in theory tractable, however.

Another thing from this implementation is that in-flight reads/writes aren't necessarily handled super well. This'll kick off a 0-length read/write for input fds, but after the function returns these are still in flight. This happens in both erroneous cases as well as successful cases. The easiest solution would probably be to cancel all in-flight reads/writes, but a more advanced solution would be to leave the in-flight read/write happening. That way subsequent calls to poll wouldn't redo a bunch of work of the previous call necessarily, but would further require more state tracking internally.

[cpetig]

Oh, I see, so the readiness would need to be stored in the descriptor and these zero size uncancelled transfers could remain active across poll calls.

I never read the specification to the end (beyond that zero size calls can be used to query readiness) but it starts making sense.

Ideally waitable-set would be reused across calls, but I didn't find an elegant solution, yet.

[alexcrichton]

To be honest I'm not sure if it's worth it to keep the zero-size transfers in flight. That'd require cancelling them, or waiting for them, during normal reads/writes as well. Overall that might be an optimization step too far for where wasi-libc is at. For now it's probably best to just enusre that by the time poll returns all active I/O is cancelled.

Overall this is all pretty horribly inefficient. For example I don't think it's possible to share the waitable-set across calls to poll. This is all just sort of architectural to the nature of poll, however, and there's not really much that can be done. I think what we'll want to do is to add some sort of __wasilibc_* public accessor of the internals of these streams so external users can build their own waitable-sets and handle the reads/writes externally. That's all further out in the future though, for now getting an inefficient poll working I think is sufficient.

[cpetig]

Oh, I just realized that there is another related implementation question: Should we combine waitable-set.wait to wait for the first event with waitable-set.poll to check for more active events. Given the overhead introduced by poll itself (especially to cancel all zero sized transactions) it should probably collect as many file events as possible within a single call.

[alexcrichton]

That's a good point yeah, and I agree it'd be reasonable to use that to report back more events