Disallow blocking_{send,recv} on wasm32

[frewsxcv]

These current don't work on wasm32 and will panic in runtime

#5548

[frewsxcv]

On second thought, maybe it makes sense to gate this on wasm32-unknown-unknown?

[Darksonn]

It's not clear to me that there's any reason to disallow these methods. If there's a message available, then they just return it like they should, and otherwise they try to block forever, and wasm currently makes anything that blocks forever panic.

[frewsxcv]

@Darksonn One of the main benefits of compiler errors is that unexpected behavior is surfaced to developers immediately rather than waiting for that particular code path is executed during runtime and potentially gets shipped to production. A developer will basically never want to call a function that unconditionally panics, and having it become a compile time error will improve the developer experience.

[Darksonn]

But it doesn't unconditionally panic. It only panics if there's no message.

[frewsxcv]

Ah that is a good point. But if you can write your program for WASM in a way that guarantees there is a message, it seems like you shouldn't be using the blocking_* calls anyways.

[Darksonn]

Still, a non-wasm-specific library might use blocking_recv. If we support the method on wasm, then you can use that library in wasm.

And what if you used the library in a case where the recv would block? Well, since wasm has no threads, this means your program would sleep forever, as nobody can ever send another message. Rust wasm has generally made the choice that all APIs that would sleep forever will panic instead, and this is an extension of that.

And if wasm-with-threads gets supported in the future, well, then that would probably include support for condvar, which would make this API start working without changes on our side.

I think, on the balance, the current choice is reasonable.