You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there are only three networking-specific functions in WASI Core -- sock_send, sock_recv, and sock_shutdown. I have an idea for how we can merge sock_send and sock_recv with fd_write and fd_read (brief mention here), since they're very similar, and I believe would make the API more flexible and easier to understand.
If we do that, a possible path forward here is to also rename sock_shutdown to fd_shutdown and say that WASI Core doesn't have explicit networking support -- it just has support for reading, writing, and (partially) shutting down streams, which can either be byte-oriented or datagram-oriented (and may or may not have in-order delivery, etc.). These might be connected to TCP or UDP sockets, or they might be connected to UNIX-domain sockets, or perhaps even something like TLSSock, or other things. The WASI Core API would limit itself to generic stream/datagram functionality. Creating and configuring (bind, connect, accept, setsockopt, etc.) sockets, or accessing protocol-specific features (sendmsg, recvmsg, etc.), would be handled by a different API module.
I do think it makes sense to consolidate send()/write() and recv()/read(). However, there may be subtle differences. We should first learn why the fence is there.
In general, I'm strongly in favor of modularizing and versioning the APIs by integrating with the WASM module system (see #74). This means we aren't stuck with the bad decisions we make today.
Yep :-). I've done some research and know quite a lot about why this particular fence is here, and even some of the accidental consequences it has. I'll write more about it when I make the actual proposal.
Activity
sunfishcode commentedon Mar 28, 2019
Currently there are only three networking-specific functions in WASI Core --
sock_send,sock_recv, andsock_shutdown. I have an idea for how we can mergesock_sendandsock_recvwithfd_writeandfd_read(brief mention here), since they're very similar, and I believe would make the API more flexible and easier to understand.If we do that, a possible path forward here is to also rename
sock_shutdowntofd_shutdownand say that WASI Core doesn't have explicit networking support -- it just has support for reading, writing, and (partially) shutting down streams, which can either be byte-oriented or datagram-oriented (and may or may not have in-order delivery, etc.). These might be connected to TCP or UDP sockets, or they might be connected to UNIX-domain sockets, or perhaps even something like TLSSock, or other things. The WASI Core API would limit itself to generic stream/datagram functionality. Creating and configuring (bind, connect, accept, setsockopt, etc.) sockets, or accessing protocol-specific features (sendmsg, recvmsg, etc.), would be handled by a different API module.What do you think of that approach?
npmccallum commentedon Mar 28, 2019
I'm all for innovation. But first watch this talk: https://www.youtube.com/watch?v=za41nQ6Ein8 :)
I do think it makes sense to consolidate
send()/write()andrecv()/read(). However, there may be subtle differences. We should first learn why the fence is there.In general, I'm strongly in favor of modularizing and versioning the APIs by integrating with the WASM module system (see #74). This means we aren't stuck with the bad decisions we make today.
sunfishcode commentedon Mar 28, 2019
Yep :-). I've done some research and know quite a lot about why this particular fence is here, and even some of the accidental consequences it has. I'll write more about it when I make the actual proposal.
sunfishcode commentedon Feb 25, 2020
Merging send/recv into read/write is now being tracked in WebAssembly/WASI#4.
Add an Instance method to lookup an exported func (bytecodealliance#69)
Fill in remaining preview1-based filesystem todos hit by wasi-tests (b…
Synchronise with upstream's `Cargo.lock`.
Synchronise with upstream's `Cargo.lock`
Merge pull request bytecodealliance#69 from type-dance/simd-enable