Support wasm (in some form)

[Thomasdezeeuw]

We can support wasm via wasi. Last I looked (for tokio-rs/mio#1395, back in November 2020) it doesn't support creating sockets, but it does support some things like read/write.

Alternatively we could start with an implementation that just panics, just so socket2 can build on wasm.

[ChenKS12138]

We can support wasm via wasi. Last I looked (for tokio-rs/mio#1395, back in November 2020) it doesn't support creating sockets, but it does support some things like read/write.

Alternatively we could start with an implementation that just panics, just so socket2 can build on wasm.

I'm interested in using socket2 in wasm too. I found that symbols like AF_INET, sa_family_t, sockaddr_in are missing in wasi, so it doesn't have the concept about the address of socket, and we could barely define SockAddr for wasm. wasi supports socket_accept, socket_recv, socket_send, socket_shutdown by far. accept in socket2 needs to return a SockAddr as the address of peer socket. So I think it seems hard to start with an implementation that just panics.

[sascha1337]

the day, wasi will have them features, will be gold for rust and thus the planet ... but wen X_X

[notgull]

Isn’t wasi an unstable API at the moment? It might not be the best idea to build on top of it.

[Thomasdezeeuw]

The API is in preview I believe, but considering it's implemented by browser backwards compatibility is everything. So I think it's find to add experimental support for wasm/wasi, this is what we did for Mio.

[thaodt]

The API is in preview I believe, but considering it's implemented by browser backwards compatibility is everything. So I think it's find to add experimental support for wasm/wasi, this is what we did for Mio.

hi @Thomasdezeeuw do we have any ways to work around now? My lib depends on tokio and tokio depends on socket2. As a result, it built failed under target wasm32-unknown-unknown (wasm-pack build --target web)

[sascha1337]

Just do some draft PoC please, we need em sockets and tokio

[Thomasdezeeuw]

hi @Thomasdezeeuw do we have any ways to work around now? My lib depends on tokio and tokio depends on socket2. As a result, it built failed under target wasm32-unknown-unknown (wasm-pack build --target web)

You might be able to disable Tokio's network feature, not sure though.

Just do some draft PoC please, we need em sockets and tokio

Prs are welcome.

[Darksonn]

Tokio only depends on socket2 if you enable the net feature, and even if you make socket2 compile under wasm somehow, I'm pretty sure that there would also be other problems with getting Tokio's net feature to work.

[miketwenty1]

can verify trying to use either crate:
awc = "3.0.0"
actix-rt = "2.7.0"
Will result in a bunch of socket2 errors when trying to compile to wasm.
such as:

/..../.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.4.4/src/socket.rs:1781:15
     |
1781 | from!(Socket, net::UdpSocket);
     |               ^^^^^^^^^^^^^^ expected struct `UdpSocket`, found `()`

Is it assumed until this issue is resolved that we won't be able to use socket2 with wasm or any libs/crates that rely on socket2?

[Lunarequest]

this should be easier to solve now that wasix exists, I'm not to sure how sockets work so I haven't taken more then a cursory build which resulting in more errors(yes you are reading that right, it seems a lot of the wasix sockets stuff expects more/less args)

[Thomasdezeeuw]

I don't know about wasix, it's doesn't seem like a standard anyone but wasmer is following. I don't really fancy having different code for different wasm runtimes.

[Lunarequest]

Wasix seems more like a pollyfill. It produces a wasm binary that should work any where

[Thomasdezeeuw]

I highly doubt that. I can't imagine how you would create a socket if the underlying wasm runtime doesn't provide a function/"system call" to create sockets.