Cool, I’ve read about that. I assumed because I saw some
std::net modules being used in the Tokio code it was dependent on the TCP and UDP mechanisms too.
It’s an educated guess from looking at
std implementation for WASM. They contain some stubs and stubs don’t always ‘work’. I’ve seen the amount of dependencies needed for
safe_app, it’s a lot! I thought the chance is there at least a few of them use something from
std:: that is stubbed (or panics) for WASM. Anyway, I can’t back it up with examples, it may be less worse than I thought looking at the stubs. Threading, syscalls and mutexes(?) won’t run on WASM, I assume — but I have no clue whether those components are used by
safe_app or its dependencies.
My point is, the low-level libraries require OS-specific code. I assume WASM isn’t quite yet ready to be a full OS-environment yet, so to me it’s vague on how these low-level libraries translate to that context.
A lot of progress is made on
wasm-bindgen, so if it doesn’t work now, it might in a few years. It’s exciting really.
Thanks for that explanation on
jemalloc, @hunterlester. The more I read the less I understand.