nurseries #22
Replies: 4 comments 9 replies
-
|
Higher-level thread management APIs like nurseries are great ideas in general, but unfortunately they aren't a great fit for WebAssembly. Nurseries and other higher-level APIs make threading more manageable by restricting how it can be used, but that means they can't easily be used to implement the more permissive threading APIs of languages that compile to Wasm. Since WebAssembly is a compilation target, we have to consider how easy it is to compile existing languages to it, not how easy it is for programmers to use directly. |
Beta Was this translation helpful? Give feedback.
-
|
The idea reminds me of structured concurrency. We discussed the possibility of that early on but, like @tlively said of this idea, structured concurrency was too difficult a target for some language's concurrency model. |
Beta Was this translation helpful? Give feedback.
-
|
I meant by that: it seems like it should be possible to provide access to unstructured spawning APIs which themselves are implemented in terms of structured APIs. (I should probably show an example of how this works, but I'm not behind a computer right now. Let me get back to my office and I can show what I mean) |
Beta Was this translation helpful? Give feedback.
-
|
Here is an example of what I meant (Rust playground): use std::{process, thread};
// The main entry point for our program
fn main() {
// Actual inner main function - this would be implemented by users
fn actual_main(scope: &std::thread::Scope<'_, '_>) {
// We can freely call `scope::spawn` in here now. This has equivalent
// semantics to calling `thread::spawn`.
//
// When exposed via `libc` `scope::spawn` would ambiently
// serve as the backend for `pthread_spawn` here.
}
thread::scope(|s| {
actual_main(s);
process::exit(0); // exit the process without joining any threads
})
}What I'm trying to say is that we can think about I don't yet understand the full tradeoffs if we were to go that route, but that's something I think we can reason through. |
Beta Was this translation helpful? Give feedback.
-
|
At that point, I don't see any benefit in having a more complex nursery setup over just a basic thread spawn. Remember that Wasm is a compilation target and our direct users are toolchain developers, who unlike library and application developers, benefit more from lower-level, simpler abstractions, even if they would be more unsafe if exposed directly to their users. Specifically, having to support older languages that have less safe threading primitives is not a backward compatibility concern for Wasm, it's a basic requirement. But thread spawning, however it looks, will happen at the component model level. Maybe the component model folks evaluate these trade offs differently and the increased isolation from using nurseries would be helpful at that level. |
Beta Was this translation helpful? Give feedback.
-
Right, yes - I don't have enough context yet about the core Wasm abstractions to comment whether the tradeoffs would be worth it. I appreciate you sharing your perspective given you have more context here than I do. To reiterate: the purpose of my comments was primarily to show that it might be possible to expose a different set of threading primitives; not to actually make the case we should prefer those over the existing proposal. I agree it would be useful to get the perspective of the current group of folks working on thread spawning in relation to this 1. I want to understand where and how the boundary for structured threading primitives should be drawn. I'll try and follow up with some folks before the next subgroup meeting to get more context. Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
The one big benefit I see is that code like to following example could be optimizable for parallelization (perhaps this can even be safely done in the web context?): (memory $memoryA 1 1)
(memory $memoryB 1 1)
(func $threading_example
(local $threadA i32)
(local $threadB i32)
;; no parallel access happens until here
;; the thread executing this function might access the memory in parallel though.
;; but this is independent of the parallelization opportunities in this function!
(call $thread.fray
(ref.func $long_computation)
(i32.const 2)
(i32.const 0) ;; unused
)
;; parallel access of memory can happen
;; but $memoryA is only accessed by thread with id 0
;; but $memoryB is only accessed by thread with id 1
;; now wait for both threads to terminate
(call $thread.splice)
;; by now all parallel access of the memory is over
;; it is for that reason that the runtime can actually parallelize the nursery without risking indeterminism
)
(func $long_computation
(param $id i32)
(param i32)
;; ...
;; ... long computation
;; ...
(call $load
(local.get $id)
(i32.const 0)
)
;; ...
;; ... long computation
;; ...
(call $store
(local.get $id)
(i32.const 0)
(i32.const 123)
)
;; ...
;; ... long computation
;; ...
)
;; for the sake of completeness the following two implementations are written out:
;; lift the immediate memory indexes of `load` and `store` to normal arguments
(func $load
(param $memory_index i32)
(param $byte_index i32)
(result i32)
(local.get $byte_index)
(if
(param i32)
(result i32)
(i32.eqz
(local.get $memory_index)
)
(then
(i32.load $memoryA)
)
(else
(i32.load $memoryB)
)
)
)
(func $store
(param $memory_index i32)
(param $byte_index i32)
(param $value i32)
(local.get $byte_index)
(local.get $value)
(if
(param i32)
(param i32)
(i32.eqz
(local.get $memory_index)
)
(then
(i32.store $memoryA)
)
(else
(i32.store $memoryB)
)
)
)
Other pros and cons I can think of: pros
cons
Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
More permissive threading APIs of languages that compile to Wasm could spawn a nursery and immediately call the How much performance can be gained / would be lost? All threads operate on temporarily unshared memory. No memory fences would be required (aside from one fence after the join.) Nurseries could be a way to make that seen by the compiler. There is lots to contemplate about but regardless of having granular nurseries or not i still expect to be able to kill a |
Beta Was this translation helpful? Give feedback.
-
Note that on the Web, Workers are expected to remain the only fundamental threading primitive, and you'll still be able to call |
Beta Was this translation helpful? Give feedback.
-
|
With nurseries it would be feasible to have (future proposals) of (non exhaustive) restrictive validation rules that would allow to have locally limited parallelism within browsers: Lets say thread The runtime could run both threads single threaded one after another. It could also do both things in parallel. Nobody (neither |
Beta Was this translation helpful? Give feedback.
-
|
I propose something like these two paired threading primitives:
(type $long_task (func (param i32) (param i32)))
;; populate nursery with threads
(func $thread.fray
(param $f (ref $long_task))
(param $n i32)
(param $c i32)
(result nursery)
;; implemented by runtime
unreachable
)
;; block until all threads terminated
(func $thread.splice
(param $nursery nursery)
;; implemented by runtime
unreachable
)The (table $orphanage 100 nursery)
(global $next_free_slot (mut i32) (i32.const 0))
(func $thread.spawn
(param $f (ref $long_task))
(param $n i32)
(param $c i32)
(table.set $orphanage
(global.get $next_free_slot)
(call $thread.allocate_i32
(local.get $f)
(local.get $n)
(local.get $c)
)
)
(global.set $next_free_slot
(i32.add
(i32.const 1)
(global.get $next_free_slot)
)
)
) |
Beta Was this translation helpful? Give feedback.
-
There is a threading concept of so called nurseries [0]. Nurseries are to threads what
if/else/switchare togotos. The insight is that nurseries are not a limitation but a liberation from complicated threading behavior and bugs.Having nurseries translates to having the
spawnfunction returning a nursery for the spawned threads. The nursery would behave like some kind of uniqueexternref. That means it cannot be copied and is not allowed to go out of scope. (It can be returned though!) Then there is a shutdown function that takes a nursery as an argument and waits for all the associated threads to finish before it returns.This is like having some kind of dog leash for each thread bundle. The simplest usage pattern is to have one or more nurseries propagate up the call stack until it reaches close to the entry point of an application where they are stashed. When the main thread wants to exit it has the means to take care of all spawned threads it was responsible of spawning. This way the main thread is able to reliable kill all lingering background threads.
Short-lived nurseries might give the compiler concrete information for optimizations. It can be ascertained that some concurrent but local operations are concluded by the time the shutdown function was called.
It was an excellent choice for
WebAssemblyto not allow access to the implicit call stack and therefor structure the control flow. An analog argumentation can be made for threads. I believe it is a good idea to explore structuring the parallel control flow of threads in a similar way.In my experience it is even better to restrict the mightiness of a new interface compared to introducing less features in a new interface. At some point in time there could be a
let_go_offunction that drops nurseries without waiting for all the threads in order to get the unrestricted behavior. Perhaps there might never be a need for the raw behavior.[0] https://www.youtube.com/watch?v=oLkfnc_UMcE
Beta Was this translation helpful? Give feedback.
All reactions