What is the plan regarding libstd and wasm syscalls?

[flo-l]

Is there desire to support things like std::time::Instant::now() etc. on wasm32-unknown-unknown? I tried to use it recently, but it seems to be behind the wasm_syscall feature flag, which is not enabled by default.

I’m not sure I understand the rationale behind this. Someone on reddit mentioned, that the wasm32-unknown-unknown triple is for “bare-bones” wasm only, without any runtime dependencies. I understand that this is a good first step, especially if the initial focus is on supplementing javascript.

But it makes porting whole applications hard. Hardly any useful rust library or binary does not use any syscalls. I tried to port the littlewing chess engine for example. While pure chess calculations do not need syscalls, the engine needs a source of time to know when to stop searching for the next move. How should one approach porting such applications to wasm?

[alexcrichton]

The wasm_syscall feature was added to the standard library in an experimental capacity and was not intended to be stabilized, but rather experiment in-tree with xargo custom cross-compilation. There are no plans at this time to stabilize the wasm_syscall feature.

In the meantime the wasm32-unknown-unknown target is envisioned as “can’t import anything” as that’s the default for almost all platforms (things like Linux only import “functionality always available”).The base WebAssembly target provides no definition of base functionality, so that’s what we’ve got to work with! This definition may be refined over time if we decide to add new targets (like wasm32-unknown-web or something like that).

In the meantime the library ecosystem around wasm provies the ability to get access to things like timers and whatnot. The web-sys crate, for example, provides access to performance.now() in the browser. You’d need to manually bind the functionality to get the current time in Node.js, and if you’re running on a different WebAssembly platform than node/browsers you’ll have to define your own way to acquire the current time.

[flo-l]

OK thank you for clarification

I want to give some feedback on my wasm-experience so far: Being able to compile code using syscalls and having it panic! during runtime felt odd. This is not how Rust works normally. I’d expect to get a compile error telling me eg. std::time::Instant::now() does not exist or similar.

Best regards!

[alexcrichton]

It’s true! We definitely understand that this feels weird. We would ideally prefer to not actually include the funcitons at all in the standard library (so your code fails to compile if it references them) but that’s not really feasible at this time (unfortunately).

Eventually we can hopefully go down that road but for now we probably just need better documentation for the wasm target that the APIs aren’t usable.

[jonh]

In the meantime the wasm32-unknown-unknown target is envisioned as “can’t import anything”

Good to read this as not (in my limited reading scope) seen such specific aim clarifying use.

(A bit or searching also answered a second question I was thinking; about maths functions; which used to be imports but see libm is now being used.)

Is the prospect of hooks on the table or something that has been rejected? (maybe in an ‘arch’ submodule.) [At same time few months ago stumbling upon wasm_syscall I spotted set_stdio used in wasm-glue]

[alexcrichton]

That’s a possibility, yes, but we haven’t decided one way or another yet. It may be worth writing an RFC though!

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.