So if your code has any processing on the JS side, threading can be dangerous
The parallel iterator is still safe because it blocks the main thread until all tasks are finished. However, if any of the tasks executed (by the rayon runtime) while the rayon threads are waiting have heap allocations, this library is potentially dangerous to use with JS-side code.
Here is sample code for the scenario described earlier
#[wasm_bindgen]
pub fn foo() {
let v = [1, 2, 3];
// this code causes a heap allocation but it's blocking the main thread so it's fine
let _ = v.iter().map(|x| x + 1).collect::<Vec<_>>();
// but after this code, there is potential to cause a heap allocation by worker threads idling tasks(?)
}
#[wasm_bindgen]
pub fn allocate_buffer(size: usize) -> *mut u8 {
let mut vec = vec![0; size].into_boxed_slice();
let ptr = vec.as_mut_ptr();
std::mem::forget(vec);
ptr
}
let ptr = wasm.allocate_buffer(10);
let t = new Uint8Array(memory.buffer, ptr, 10); // create typed array based pointer
t[0] = 1;
wasm.foo(); // the pointer may be invalidated because memory.grow may be executed
if (t.length !== 10) {// So we check to see if the pointer is valid
t = new Uint8Array(memory.buffer, ptr, 10); // If it is invalidate, create a new pointer
// In a WASM in a single-threaded environment,
// we only need to check that the pointer is valid once before accessing it,
// but in a multithreaded scenario,
// this is not a safe thing to do because memory.grow can be executed by a worker thread.
}
console.log(t[0]);
For this reason If the rayon runtime is guaranteed not to do any heap allocation when all workerthreads are idle, it seems to be safe to use. So I'm curious about this.
When memory.grow on the WASM side, all typed array based pointers created in js are invalidated. see: https://github.com/rustwasm/wasm-bindgen/issues/2222
So if your code has any processing on the JS side, threading can be dangerous
The parallel iterator is still safe because it blocks the main thread until all tasks are finished. However, if any of the tasks executed (by the rayon runtime) while the rayon threads are waiting have heap allocations, this library is potentially dangerous to use with JS-side code.
Here is sample code for the scenario described earlier
For this reason If the rayon runtime is guaranteed not to do any heap allocation when all workerthreads are idle, it seems to be safe to use. So I'm curious about this.