RFC: Exposing WASM runtime to Erlang applications #5
Description
This issue is for discussing how we can expose the Wasm runtime to Erlang applications.
The Wasm runtime is an extension of the core runtime with APIs which match the browser APIs, so things like alert, document.getElementById, etc. These APIs will be primarily generated via something like wasm-bindgen, and should ideally be callable from LLVM IR.
There are non-trivial issues to be sorted out here though:
- Calling DOM APIs generally requires support for events/callbacks
- Calling these APIs also requires us to convert Erlang terms to the types expected by the APIs
In particular, the handling of events/callbacks requires careful planning. In Wasm we are planning to dedicate the main thread "scheduler" as more of an event loop that yields back to the JS runtime like a typical JS application would, while the more traditional scheduler threads would run in one or more WebWorkers.
In order to call DOM APIs, it is then necessary for a process wishing to perform such a call, to dispatch a request to the main thread, which would then be suspended by its scheduler, while the main thread would then take responsibility for calling the API, yielding to the JS runtime, and then once the result is received, ensure that the process is woken up so that it can resume execution where it left off. I'm not yet sure whether or not we should try and mimic the continuation-passing style common to JS, or whether we should transparently convert these to await/async equivalents, where calling an API will appear to be blocking, but under the covers constructs a continuation which is then invoked with the result of the call once received.
Related to that, callbacks could then be implemented transparently, either as a continuation, or by constructing a closure which is called with the arguments given to the callback. The main thread will have a generic callback handler which will be the "real" function pointer passed to the JS API, so that it is invoked by the JS side when the callback is invoked. This handler will then construct the closure/continuation value for the origin process, which will be resumed using that value.
Events would more than likely work on a similar mechanism - a subscription would be set up by sending the request to the main thread, which would track the requesting PID, and as part of its event loop, would then dispatch any received events to subscribers by looking up the relevant PIDs and pushing messages onto their signal queue.
In short, the task list is basically these items:
- Design/sketch out the mechanism by which callbacks will be handled
- Design/sketch out the mechanism by which events will be handled
- Design/sketch out the semantics of invoking DOM/browser APIs, using the design of the above two points to ensure we have a complete specification of how we interface with JS APIs.
- Implement each of the above