While this doesn’t answer the question, and apologies if you’re aware of this already… if you just want a bidirectional bytestream, you are probably better off implementing an interface like select()/poll(). Actually, while I have zero WASI experience, it seems like it has one already. This is not the same as “polling” as in checking over and over; rather, the WASM program makes a list of conditions like “data available to read” or “buffer space available to write”, and performs a syscalls which blocks until any of those conditions is met. Then the actual read/write call can be done without blocking. (There is also a design variant where the whole read/write operation is scheduled in advance and the blocking syscall just notifies you which previously scheduled operation has completed, similar to Windows IOCP or Linux io_uring.)
No no, you're right in the thick of the issue, so thank you for your comment :)
At issue is the fact that select/poll requires integration into the language runtime of whatever has been compiled to WASM. For example, imagine that you've compiled an application written in Go to WASM and you want to create a syscall that is analogous to select while still being a distinct thing. The problem you run into is this: what if there's a timer that's going to fire in 500µs? You have no way of determining that and setting your `select` timeout accordingly. To do so would require hacking the Go runtime itself, along with the compiler.
>There is also a design variant where the whole read/write operation is scheduled in advance and the blocking syscall just notifies you which previously scheduled operation has completed, similar to Windows IOCP or Linux io_uring.
I'm not sure I'm fully grasping the distinction, but it seems appealing... can you elaborate? Or is there something I could read/watch?
