poll_oneoff() implementation

[cjihrig]

This and the sockets calls (which might be going away from WASI anyway) are the only completely unimplemented calls.

I'm still trying to figure out the best way forward here. From what I can tell, this is a synchronous call, so I'm not sure that uv_poll_t can be used.

Also, as @saghul pointed out in nodejs/wasi#21 (comment), polling non-sockets on Windows could be an issue.

[saghul]

I guess you could create a new loop, put all poll handles in there and wait for it to finish, then return. Somewhat akin to what Node does for spawnSync, IIRC.

Now, if socket calls are going away what stuff can one poll on, just timers?

[cjihrig]

Now, if socket calls are going away what stuff can one poll on, just timers?

According to the docs, you can poll on __WASI_EVENTTYPE_CLOCK, __WASI_EVENTTYPE_FD_READ, and __WASI_EVENTTYPE_FD_WRITE. Even if the socket API calls go away, I wonder if it would be feasible (on Windows only) to open a socket along with each file descriptor for polling purposes. I'm just kind of thinking out loud though.

Unfortunately, from what I can tell, the WASI API wasn't designed with first class Windows support in mind.

[saghul]

I see. The fun fact is that in it's current shape we can't use uv_poll_t for non-scket fds, because epoll doesn't support files... You could roll a manual poll() for the fds, because that works with files, but it's broken on macOS and on Windows IIRC.

So that leaves timers. Maybe a good starting point is to just implement timers and claim that any other event type is always ready?

Also thinking out loud here :-)

[cjihrig]

For reference, here is how wasmtime implemented it: https://github.com/CraneStation/wasmtime/blob/e530a582afe6a2b5735fd7cdf5e2e88391e58669/wasmtime-wasi-c/sandboxed-system-primitives/src/posix.c#L2303-L2530

And this is how Gus implemented it in JavaScript: https://github.com/devsnek/node-wasi/blob/12a0985a46589587facd8d8e161911650ef15f3b/src/index.js#L1169-L1247. I'm not sure if the JS version works or not, given that the poll test is skipped in that repo.

[cjihrig]

Hi @saghul 👋

I've been revisiting this lately. I think I have an implementation based on uv_poll_t mostly working. I had two questions/ideas that I wanted to run by you:

1. Regarding Windows support - uv_poll_t only works with sockets on Windows. Based on these poll() docs, I think it would be OK to always return success for regular files as well. Anything else can just not be supported on Windows for now. Does that make sense to you?

2. One potential issue that I see is that libuv doesn't support multiple poll handles for the same file. However, there is nothing stopping a WASI user from calling poll_oneoff() with the same descriptor multiple times, potentially polling for different events on it. My thought here was to detect duplicate inputs and dup() the fd for the duration of the poll. Do you think that would work?

[saghul]

1. Regarding Windows support - `uv_poll_t` only works with sockets on Windows. Based on [these `poll()` docs](https://docs.oracle.com/cd/E23824_01/html/821-1463/poll-2.html), I think it would be OK to always return success for regular files as well. Anything else can just not be supported on Windows for now. Does that make sense to you?

Yeah!

2\. One potential issue that I see is that libuv doesn't support multiple poll handles for the same file. However, there is nothing stopping a WASI user from calling `poll_oneoff()` with the same descriptor multiple times, potentially polling for different events on it. My thought here was to detect duplicate inputs and `dup()` the fd for the duration of the poll. Do you think that would work?

That might work. But since you also need to keep track of the fds (right?) maybe just remeember them and edit the event mask, then rearm the poll handle?

[cjihrig]

But since you also need to keep track of the fds (right?) maybe just remeember them and edit the event mask, then rearm the poll handle?

Yes, there is a fair amount of state, including the fds, to track. I'm going to try your suggestion. Thanks!