Parallel Raytracing - The wasm-bindgen Guide (original) (raw)

1. Introduction
2. 1. Examples
3. 1. 1.1. Hello, World!
   2. 1.2. Using console.log
   3. 1.3. Small Wasm files
   4. 1.4. Without a Bundler
   5. 1.5. Synchronous Instantiation
   6. 1.6. Importing functions from JS
   7. 1.7. Working with char
   8. 1.8. js-sys: WebAssembly in WebAssembly
   9. 1.9. web-sys: DOM hello world
   10. 1.10. web-sys: Closures
   11. 1.11. web-sys: performance.now
   12. 1.12. web-sys: using fetch
   13. 1.13. web-sys: Weather report
   14. 1.14. web-sys: canvas hello world
   15. 1.15. web-sys: canvas Julia set
   16. 1.16. web-sys: WebAudio
   17. 1.17. web-sys: WebGL
   18. 1.18. web-sys: WebSockets
   19. 1.19. web-sys: WebRTC DataChannel
   20. 1.20. web-sys: requestAnimationFrame
   21. 1.21. web-sys: A Simple Paint Program
   22. 1.22. web-sys: Wasm in Web Worker
   23. 1.23. Parallel Raytracing
   24. 1.24. Wasm Audio Worklet
   25. 1.25. web-sys: A TODO MVC App
4. 2. Reference
5. 1. 2.1. Deployment
   2. 2.2. JS snippets
   3. 2.3. Static JS Objects
   4. 2.4. Passing Rust Closures to JS
   5. 2.5. Receiving JS Closures in Rust
   6. 2.6. Promises and Futures
   7. 2.7. Iterating over JS Values
   8. 2.8. Arbitrary Data with Serde
   9. 2.9. Accessing Properties of Untyped JS Values
   10. 2.10. Working with Duck-Typed Interfaces
   11. 2.11. Command Line Interface
   12. 2.12. Optimizing for Size
   13. 2.13. Supported Rust Targets
   14. 2.14. Supported Browsers
   15. 2.15. Support for Weak References
   16. 2.16. Support for Reference Types
   17. 2.17. Supported Types
   18. 1. 2.17.1. Imported JavaScript Types
       2. 2.17.2. Exported Rust Types
       3. 2.17.3. JsValue
       4. 2.17.4. Box<[T]> and Vec
       5. 2.17.5. *const T and *mut T
       6. 2.17.6. NonNull
       7. 2.17.7. Numbers
       8. 2.17.8. bool
       9. 2.17.9. char
       10. 2.17.10. str
       11. 2.17.11. String
       12. 2.17.12. Number Slices
       13. 2.17.13. Boxed Number Slices
       14. 2.17.14. Result<T, E>
   19. 2.18. #[wasm_bindgen] Attributes
   20. 1. 2.18.1. On JavaScript Imports
       2. 1. 2.18.1.1. catch
             1. 2.18.1.2. constructor
             2. 2.18.1.3. extends
             3. 2.18.1.4. getter and setter
             4. 2.18.1.5. final
             5. 2.18.1.6. indexing_getter, indexing_setter, and indexing_deleter
             6. 2.18.1.7. js_class = "Blah"
             7. 2.18.1.8. js_name
             8. 2.18.1.9. js_namespace
             9. 2.18.1.10. method
             10. 2.18.1.11. module = "blah"
             11. 2.18.1.12. raw_module = "blah"
             12. 2.18.1.13. no_deref
             13. 2.18.1.14. static_method_of = Blah
             14. 2.18.1.15. structural
             15. 2.18.1.16. typescript_type
             16. 2.18.1.17. variadic
             17. 2.18.1.18. vendor_prefix
       3. 2.18.2. On Rust Exports
       4. 1. 2.18.2.1. constructor
             1. 2.18.2.2. js_name = Blah
             2. 2.18.2.3. js_class = Blah
             3. 2.18.2.4. readonly
             4. 2.18.2.5. skip
             5. 2.18.2.6. skip_jsdoc
             6. 2.18.2.7. start
             7. 2.18.2.8. main
             8. 2.18.2.9. typescript_custom_section
             9. 2.18.2.10. getter and setter
             10. 2.18.2.11. inspectable
             11. 2.18.2.12. skip_typescript
             12. 2.18.2.13. getter_with_clone
             13. 2.18.2.14. unchecked_return_type and unchecked_param_type
             14. 2.18.2.15. return_description and param_description
6. 3. web-sys
7. 1. 3.1. Using web-sys
   2. 3.2. Cargo Features
   3. 3.3. Function Overloads
   4. 3.4. Type Translations
   5. 3.5. Inheritance
   6. 3.6. Unstable APIs
8. 4. Testing with wasm-bindgen-test
9. 1. 4.1. Usage
   2. 4.2. Writing Asynchronous Tests
   3. 4.3. Testing in Headless Browsers
   4. 4.4. Continuous Integration
   5. 4.5. Coverage (Experimental)
10. 5. Contributing to wasm-bindgen
11. 1. 5.1. Testing
12. 5.2. Internal Design
13. 1. 5.2.1. JS Objects in Rust
       1. 5.2.2. Exporting a function to JS
       2. 5.2.3. Exporting a struct to JS
       3. 5.2.4. Importing a function from JS
       4. 5.2.5. Importing a class from JS
       5. 5.2.6. Rust Type conversions
       6. 5.2.7. Types in wasm-bindgen
14. 5.3. js-sys
15. 1. 5.3.1. Testing
       1. 5.3.2. Adding More APIs
16. 5.4. web-sys
17. 1. 5.4.1. Overview
       1. 5.4.2. Testing
       2. 5.4.3. Logging
       3. 5.4.4. Supporting More Web APIs
18. 5.5. Publishing
19. 5.6. Team

The `wasm-bindgen` Guide

Parallel Raytracing

View full source code or view the compiled example online

This is an example of using threads with WebAssembly, Rust, and wasm-bindgen, culminating in a parallel raytracer demo. There's a number of moving pieces to this demo and it's unfortunately not the easiest thing to wrangle, but it's hoped that this'll give you a bit of a taste of what it's like to use threads and Wasm with Rust on the web.

Building the demo

One of the major gotchas with threaded WebAssembly is that Rust does not ship a precompiled target (e.g. standard library) which has threading support enabled. This means that you'll need to recompile the standard library with the appropriate rustc flags, namely-C target-feature=+atomics,+bulk-memory,+mutable-globals. Note that this requires a nightly Rust toolchain.

To do this you can use the RUSTFLAGS environment variable that Cargo reads:

export RUSTFLAGS='-C target-feature=+atomics,+bulk-memory,+mutable-globals'

To recompile the standard library it's recommended to use Cargo's-Zbuild-stdfeature:

cargo build --target wasm32-unknown-unknown -Z build-std=panic_abort,std

Note that you can also configure this via .cargo/config.toml:

[unstable]
build-std = ['std', 'panic_abort']

[build]
target = "wasm32-unknown-unknown"
rustflags = '-Ctarget-feature=+atomics,+bulk-memory,+mutable-globals'

After this cargo build should produce a WebAssembly file with threading enabled, and the standard library will be appropriately compiled as well.

The final step in this is to run wasm-bindgen as usual, and wasm-bindgenneeds no extra configuration to work with threads. You can continue to run it through wasm-pack, for example.

Running the demo

Currently it's required to use the --target no-modules or --target web flag with wasm-bindgen to run threaded code. This is because the WebAssembly file imports memory instead of exporting it, so we need to hook initialization of the wasm module at this time to provide the appropriate memory object. This demo uses --target no-modules, because Firefox does not support modules in workers.

With --target no-modules you'll be able to use importScripts inside of each web worker to import the shim JS generated by wasm-bindgen as well as calling the wasm_bindgen initialization function with the shared memory instance from the main thread. The expected usage is that WebAssembly on the main thread will post its memory object to all other threads to get instantiated with.

Caveats

Unfortunately at this time running Wasm on the web with threads has a number of caveats, although some are specific to just wasm-bindgen. These are some pieces to consider and watch out for, although we're always looking for improvements to be made so if you have an idea please file an issue!

• The main thread in a browser cannot block. This means that if you run WebAssembly code on the main thread you can never block, meaning you can't do so much as acquire a mutex. This is an extremely difficult limitation to work with on the web, although one workaround is to run Wasm exclusively in web workers and run JS on the main thread. It is possible to run the same wasm across all threads, but you need to be extremely vigilant about synchronization with the main thread.
• Setting up a threaded environment is a bit wonky and doesn't feel smooth today. For example --target bundler is unsupported and very specific shims are required on both the main thread and worker threads. These are possible to work with but are somewhat brittle since there's no standard way to spin up web workers as Wasm threads.
• There is no standard notion of a "thread". For example the standard library has no viable route to implement the std::thread module. As a consequence there is no concept of thread exit and TLS destructors will never run. We do expose a helper, __wbindgen_thread_destroy, that deallocates the thread stack and TLS. If you invoke it, it must be the last function you invoke from the Wasm module for a given thread.
• Any thread launched after the first one might attempt to block implicitly in its initialization routine. This is a constraint introduced by the way we set up the space for thread stacks and TLS. This means that if you attempt to run a Wasm module in the main thread after you are already running it in a worker, it might fail.
• Web Workers executing WebAssembly code cannot receive events from JS. A Web Worker has to fully return back to the browser (and ideally should do so occasionally) to receive JS messages and such. This means that common paradigms like a rayon thread pool do not apply straightforward-ly to the web. The intention of the web is that all long-term blocking happens in the browser itself, not in each thread, but many crates in the ecosystem leveraging threading are not necessarily engineered this way.

These caveats are all largely inherited from the web platform itself, and they're important to consider when designing an application for threading. It's highly unlikely that you can pull a crate off the shelf and "just use it" due to these limitations. You'll need to be sure to carefully plan ahead and ensure that gotchas such as these don't cause issues in the future. As mentioned before though we're always trying to actively develop this support so if folks have ideas about how to improve, or if web standards change, we'll try to update this documentation!

Browser Requirements

This demo should work in the latest Firefox and Chrome versions at this time, and other browsers are likely to follow suit. Note that threads andSharedArrayBuffer require HTTP headers to be set to work correctly. For more information see the documentation on MDNunder "Security requirements" as well as Firefox's rollout blog post. This means that during local development you'll need to configure your web server appropriately or enable a workaround in your browser.