Stream: rust-toolchain

Topic: Threads

Alexandru Ene (Mar 21 2022 at 16:43):

Is there any current ongoing work to bring threads into the rust std library implementation? At the moment it panics due to: https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/library/std/src/sys/wasi/thread.rs#L16

Dan Gohman (Mar 21 2022 at 16:49):

No; wasi itself doesn't yet have a way to create threads; until we have that, there isn't much that can be done on the producer toolchain side.

Alexandru Ene (Mar 21 2022 at 16:51):

Ah right, so the extension here is non-standard, I must have missed that https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/pthread_library.md

Alexandru Ene (Mar 21 2022 at 17:00):

Is there a proposal for pthread-like API in WASI? I can only seem to find some issues where this is briefly discussed, but nothing beyond that.

Dan Gohman (Mar 21 2022 at 17:02):

As far I'm aware, nothing has changed since this post.

Andrew Brown (Mar 22 2022 at 01:52):

@Alexandru Ene, I have been experimenting with wasi-parallel, a way to express a "parallel for" from WASI; are you dead set on needing pthread-like support?

Alexandru Ene (Mar 22 2022 at 11:22):

The thing I think would be hugely beneficial would be for rust apps using threads to just work when compiled to wasm32-wasi. A pthread-like support would as far as I understand solve that since one could implement the rust Thread interface from above using it.

Alexandru Ene (Mar 22 2022 at 17:33):

Sorry, I wrote this and forgot to send it:
Things like rayon, etc would _just work_ if we can support Threads from the stdlib

Dan Gohman (Mar 22 2022 at 17:34):

Ultimately, there are limited resources for advancing things that "Make It Just Work".

Dan Gohman (Mar 22 2022 at 17:36):

Even something as seemingly obvious as a a single-threaded stub implementation of <pthread.h> to allow code using it to at least compile, which many people have asked for, has never seen anyone volunteer to create a PR.

Dan Gohman (Mar 22 2022 at 17:37):

So we've had to prioritize. And sometimes, the priority of building out a weird slow Unix clone has been lower than the priority of trying to build the best system we can on top of the new component model platform forming underneath us.

Dan Gohman (Mar 22 2022 at 17:38):

But of course, many people just want the weird slow Unix clone.

Dan Gohman (Mar 22 2022 at 17:39):

And they want someone else to build it for them.

Dan Gohman (Mar 22 2022 at 17:44):

Threads in WASI aren't going to happen until someone steps up to make a proposal to add native threads to Wasm. I've talked to numerous people who wanted this to happen over the last 2 years, and no one has actually stepped up.

Dan Gohman (Mar 22 2022 at 17:45):

I myself am not going to do it.

Dan Gohman (Mar 22 2022 at 17:45):

So if it's going to happen, someone is going to have to step up.

Alexandru Ene (Mar 22 2022 at 17:48):

Oh yes, I wasn't suggesting someone should do it, i meant more what i envision the target experience to be like from a library user's perspective. "You include rayon, or any code that used the standard's library Thread class, it should keep working with threads enabled just as it does natively."

Alexandru Ene (Mar 22 2022 at 17:49):

I'm more than happy to pick this up tbh since it's an area we're interested in improving (at Prime Video)

Alexandru Ene (Mar 22 2022 at 17:50):

That's why I asked for a status, and the comment link is a good summary.

Alexandru Ene (Mar 22 2022 at 17:50):

I'm looking to understand where we are and what a good next step would be :smile:

Alexandru Ene (Mar 22 2022 at 17:57):

And from what I see so far, a WASI-thread proposal would be a good next step, at least we can define an API that can then be implemented in terms of what VM capabilities we get. It's a bit unclear so far how much WASI is willing to not be compatible with browsers for example, or if there is such a goal

Alexandru Ene (Mar 22 2022 at 18:02):

Or maybe I lack a bit of understanding on the dependency for threads in WASI to thread creation / join being defined in WASM. Since a WASI extension would be compatible with the current standard, or maybe i'm missing something

Alexandru Ene (Mar 22 2022 at 18:05):

I've registered for the next WASI meeting to try and understand this a bit better

Alexandru Ene (Mar 22 2022 at 18:36):

@Andrew Brown I did read the wasi-parallel and it seems useful with a more limited scope (parallel-for style computation). It reminded me of how open-mp extensions

Andrew Brown (Mar 22 2022 at 19:01):

Yeah, actually OpenMP is something we are looking into. But now that I understand the "just make rayon work" use case, I think there may be some opportunities to work together. Initially we were quite hesitant to do pthread-like create/join because there seemed to be a lot of pitfalls, e.g., in 2018 @Alex Crichton made rayon work on the browser and he identified some key problems with the Wasm threads proposal that made things... not easy: see this list of caveats. What do you think of those? Some are a bit browser specific...

Alexandru Ene (Mar 22 2022 at 19:03):

I'll give it a read, thanks for referencing it!

Andrew Brown (Mar 22 2022 at 19:04):

Threads in WASI aren't going to happen until someone steps up to make a proposal to add native threads to Wasm. I've talked to numerous people who wanted this to happen over the last 2 years, and no one has actually stepped up.

@Dan Gohman, native threads in Wasm proper? Or is there some way to do it with WASI and the existing thread proposal?

Dan Gohman (Mar 22 2022 at 19:08):

In the posts linked from here, the consensus seems to be that the Web Worker system for threads isn't something we want to carry forward into non-Web contexts that don't have Web constraints.

Dan Gohman (Mar 22 2022 at 19:09):

Technically speaking, it would work. WASI could define concepts which play the role of Web Workers, and we could build essentially the same threading system that browsers have, in a WASI context.

Dan Gohman (Mar 22 2022 at 19:11):

However, the wasm libpthread would need to be very different. Because in Web Workers, each thread is a separate wasm instance, which is different from how "native" threads in wasm are envisioned to work.

Alexandru Ene (Mar 22 2022 at 19:14):

Would we need a WASM "native" threads accepted proposal in order to propose a pthread-like API for "native" threads in WASI? From my investigation so far, "native" threads exposed through an WASI API would require some changes in the thread-safety of other methods, but don't necessarily require new WASM instructions (maybe i'm super wrong here, I've just started looking into this more deeply)

Alexandru Ene (Mar 22 2022 at 19:16):

My reading of the WASM standard so far is that it has added OPS that are concerned with atomic access to variables, they wouldn't be incompatible with "native" threads

Dan Gohman (Mar 22 2022 at 19:16):

I'm not sure. The first thing I think we'd need is an answer to "how does one create a new thread?"

Dan Gohman (Mar 22 2022 at 19:17):

And in answering that, we'll need to figure out how the new thread gains access to the linear memory, and how TLS works.

Andrew Brown (Mar 22 2022 at 19:18):

I've read Dan's comments a few times in the past, but only now do I feel like I "get" them (at least in part). The Web Worker "each thread is a separate instance" is a big design decision that we would have to buy into... or not. Right now I don't see why not: the globals would remain thread-local and all we would need is to build support for shared memory in Wasmtime (I'm looking into this) and figure out what to do about the "start" function...

Alexandru Ene (Mar 22 2022 at 19:19):

Ok, if you want we can work together on this @Andrew Brown . I'm really interested to get something moving in this direction, and since you already have some experience with the openmp-style parallel for it would help a bunch.

Andrew Brown (Mar 22 2022 at 19:23):

@Dan Gohman: I don't want to get sucked into a "boil the ocean" problem, but I am semi-hopeful that creating wasi_thread_create and wasi_thread_join are possible with "one instance per thread"... Beyond the following, what other things are missing to make this happen: 1) what to do about "start" function, 2) shared memory support in Wasmtime, 3) implement wait/notify instructions from the threads proposal in Wasmtime, 4) maybe finish out any missing atomic instructions in Wasmtime (most seem to be there)--what else?

Andrew Brown (Mar 22 2022 at 19:26):

5) support in the Rust stdlib to map thread functions to the WASI ones when compiled to wasm32-wasi

Dan Gohman (Mar 22 2022 at 19:29):

I myself don't know what would be needed to make instance-per-thread happen. I'm under the assumption that instance-per-thread isn't the system we'll ultimately want. Building it will not only be redundant work in the long run, but it'll mean building the system we'll ultimately want will be more work, because we'll have to deal with the transition.

Andrew Brown (Mar 22 2022 at 19:29):

isn't the system we'll ultimately want

Andrew Brown (Mar 22 2022 at 19:29):

Why?

Dan Gohman (Mar 22 2022 at 19:30):

For the reasons in the links in https://github.com/WebAssembly/WASI/issues/296#issuecomment-659223938

Alexandru Ene (Mar 22 2022 at 19:32):

I'm also leaning more towards the not-instance-per-thread model, but I'll think a bit more about what the best way forward would be

Dan Gohman (Mar 22 2022 at 19:32):

@Alexandru Ene To answer one of your earlier questions: a "native" threads approach wouldn't be compatible with browsers at first, but (a) that isn't necessarily a blocker for WASI, and (b) in some of those threads, folks working on browsers are also weighing in saying they'd like a more light-weight way to do threads than Web Workers, so it's possible that browsers could eventually support a "native" thread system too.

Alexandru Ene (Mar 22 2022 at 20:41):

Thanks for clarifying @Dan Gohman . Your help is really appreciated :smile:

Alexandru Ene (May 04 2022 at 13:59):

I've kickstarted this: https://github.com/AlexEne/wasi-native-threads/blob/main/README.md
As well as added a proposal initial discussion for tomrrow's meeting: https://github.com/WebAssembly/meetings/pull/1024

It's really early days, but got to start somewhere :grinning:

Last updated: Dec 23 2024 at 14:03 UTC