I am going to ask about a fundamental problem of socket APIs like who is going to create a socket and pass it to a .wasm module in a standalone runtime?
Let's say there are two programs in language C, a TCP server and a TCP client. Both use POSIX socket APIs(like socket(), bind(), accept(), listen(), and so on). The goal is to translate both into WASM modules and to run in a standalone runtime.
According to the design limitation of cloudabi, I learned that there should be someone to create the socket resource outside the WASM world and pass it to WASM modules. (I guess this is the reason there are only recv() and send() in WASI).
Does it mean the compiling tool (from C to WASM) should generate an additional glue code to work with the WASM module lately? Otherwise, I think another way is to ask authors of programs to split their code into several parts.
I am going to ask about a fundamental problem of socket APIs like who is going to create a socket and pass it to a .wasm module in a standalone runtime?
Let's say there are two programs in language C, a TCP server and a TCP client. Both use POSIX socket APIs(like
socket()
,bind()
,accept()
,listen()
, and so on). The goal is to translate both into WASM modules and to run in a standalone runtime.According to the design limitation of cloudabi, I learned that there should be someone to create the socket resource outside the WASM world and pass it to WASM modules. (I guess this is the reason there are only
recv()
andsend()
in WASI).Does it mean the compiling tool (from C to WASM) should generate an additional glue code to work with the WASM module lately? Otherwise, I think another way is to ask authors of programs to split their code into several parts.