poll_oneoff should return subscription specific errno via events rather than the return value

[mitchellh]

This is not specified either way so I'm not sure if this is a bug or not, but I will explain my motivation for why I believe the current behavior is difficult to program around.

I also don't know if an issue is the correct way to report this, I couldn't find any guidelines but I could've easily missed those. Sorry!

Current behavior: If any of the passed in subscriptions with poll_oneoff have an FD that doesn't have the poll_fd_readwrite right, poll_oneoff itself returns a perm errno. I've reproduced this bug (?) in only two runtimes: wasmtime and wasmer. I'm not sure if this is a spec bug, a runtime bug, or not a bug at all and is expected behavior.

Expected behavior: The perm errno should be set in the event out parameter for the specific subscription(s) that it applies to.

Why? In the current behavior, if I am polling a large number of subscriptions -- say 100 file descriptors -- it is impossible for me to figure out which subscription is the problem. I can manually fd_stat every FD prior to using it but this adds unnecessary "syscall" overhead when the expected path is that I have the perm.

I'm not sure if POSIX poll(2) behaves similarly since I only have experience with the newer async IO subsystems. The man page seems to imply that POLLERR will be set on the output event rather than as a poll return value itself. But, I haven't tried.

What I do know is that io_uring, epoll, and kqueue will all specify error codes like this on the request itself (not as an error code of the kqueue, epoll_wait, etc. syscalls). It isn't directly comparable since they don't have an identical "rights" system like WASI but I think it is relevant information. It enables the behavior I'm looking for.

[sunfishcode]

Thanks for the report!

Your suggestion here to have poll report errors as events rather than having the whole poll fail makes sense to me. It's really appealing to say that poll itself should never fail, because it's not doing any I/O itself. That also lines up well with the wait design in the async proposal. So I believe we should document this behavior, and then update the implementations to follow.

I also think you're right that the "rights" system in WASI is one of the things that led us to having poll work this way in practice. As it turns out, the rights system was introduced at the beginning, but in practice has ended up causing a lot of confusion without adding much value. We've actually removed it altogether in preview2, which is the next major iteration of WASI currently in development.

[sunfishcode]

The poll-oneoff API in this repo no longer has a result return type, but we should also document how errors are reported.

[sunfishcode]

I filed WebAssembly/wasi-io#48 to track the documentation issue here.