search

WebAssembly / wasi-libc

WASI libc implementation for WebAssembly
https://wasi.dev
Other
812 stars 188 forks source link

implement basic TCP/UDP client support #477

Closed dicej closed 2 months ago

dicej commented 3 months ago

This implements socket, connect, recv, send, etc. in terms of wasi-sockets for the wasm32-wasi-preview2 target.

I've introduced a new public header file: __wasi_snapshot.h, which will define a preprocessor symbol __wasilibc_use_preview2 if using the wasm32-wasi-preview2 version of the header, in which case we provide features only available for that target.

jeffparsons commented 2 months ago

Am I correct in thinking that @sunfishcode has outstanding concerns here? (Just trying to figure out the status of this PR / where the ball is.)

dicej commented 2 months ago

Am I correct in thinking that @sunfishcode has outstanding concerns here? (Just trying to figure out the status of this PR / where the ball is.)

Yeah, IIUC @sunfishcode thinks maybe send should flush to conform to POSIX error reporting expectations and @badeend thinks that's unnecessary overhead. I'm fine either way and will do whatever's necessary to get this merged. @badeend perhaps I could add the flush for now and we can revisit later just to keep this process moving?

badeend commented 2 months ago

IIUC @sunfishcode thinks maybe send should flush to conform to POSIX error reporting expectations and @badeend thinks that's unnecessary overhead.

I'm not worried about performance. The point I'm trying to get across is that, IMO, not flushing is the desired POSIX semantics. Waiting around for a potential error (through flushing) would break the non-blocking-ness of non-blocking sockets.

sunfishcode commented 2 months ago

I think I'm not confident in the flush situation yet, however I'm thinking that we can merge this PR as-is, once the conflicts are resolved, and figure out the right flush usage over time.

sunfishcode commented 2 months ago

Thanks!