Stream: wasi

Topic: component model threading system questions

Soni L. (Sep 25 2024 at 17:50):

why is threading limited to threads?

Soni L. (Sep 25 2024 at 18:03):

why are threads provided by component model?

Soni L. (Sep 25 2024 at 18:04):

can't we make an API that provides for a host to provide an API for threads?

Soni L. (Sep 25 2024 at 18:04):

(or even like popen or async-signal safety)

Soni L. (Sep 25 2024 at 18:05):

there's this amazing paper we've been reading that in our opinion basically does away with the need of language support for threads http://tom7.org/papers/modal-types-for-mobile-code.pdf

Chris Fallin (Sep 25 2024 at 18:07):

There are a bunch of questions here but to add a note on the last: tom7's dissertation is certainly interesting, but the goal of WASI is (I think) not to pull in advanced type system features and do something radically different -- there is only so much innovation budget to take in one step

Soni L. (Sep 25 2024 at 18:11):

we need interrupt handling in component model if we wanna be able to stick component model in microcontrollers

Soni L. (Sep 25 2024 at 18:13):

someone recently made a custom-page-sizes proposal that makes wasm far more viable in microcontrollers than it's ever been, it'd be unfortunate if we couldn't use it due to lack of support for interrupt handling

Chris Fallin (Sep 25 2024 at 18:14):

I'm not sure why you have strikeout over all your text, and interrupt handling is a different question than either threading or modal types above, but re: embedded use-cases, @Dan Gohman has done some thinking around this

Soni L. (Sep 25 2024 at 18:15):

the reason is that modal types solve both threading and interrupt handling

Chris Fallin (Sep 25 2024 at 18:19):

Ah, OK. You're certainly welcome to propose a design based around that in more detail (linking to a dissertation alone is not enough), but keep in mind what I said above: there's only so much innovation budget we can spend; something that diverges radically from the way these use-cases are usually solved will have an uphill battle

Soni L. (Sep 25 2024 at 18:19):

it's the concept of worlds (not to be confused with component model worlds - also why are component model worlds called worlds if they don't seem to provide any actual isolation? but anyway) that makes it work for these things

Chris Fallin (Sep 25 2024 at 18:24):

Design proposals would be interesting but I'd encourage you to keep a few principles in mind:

• Black-and-white thinking based on "this idea will solve the problem, why do it any other way" is generally not as convincing or helpful to others; try to frame things in terms of tradeoffs. It's clear to me we could solve interrupts in a bunch of different ways: reentrant calls into Wasm, messages to an event loop, etc. Latching onto one idea and discarding all others prematurely is a bad way to come to consensus in a standards context
• Extremely vague statements ("why are threads limited to threads") are generally unhelpful: others don't have the context that you do, and we can't read your mind, nor do most folks want to sit down and read a whole dissertation. Examples and succinct explanations go a long way
• I'd again (similar to the thread the other day) encourage you to hold the existing design with a bit more curiosity and humility: "why is it X if it doesn't actually..." "it's a bad scripting language" "it's just RPC" etc... there has been a lot of thinking into the current architecture and there are good reasons for most of the choices, if something is perplexing to you it's worthwhile trying to understand what design tradeoffs may have led folks to the choices they made. That can also help inform further thinking about new solutions. It's usually the case that systems are not designed so poorly that one can jump in, instantly know better, discard everything and propose a radically better approach -- or if that is the case, let's see a detailed explanation why

Soni L. (Sep 25 2024 at 18:41):

the reason we're bringing it up now is that we believe it's not yet too late to discuss it, unlike... the unfortunate fact that the GC proposal allows cyclic references, which we're slightly upset about. well anyway, no point in discussing that.

the simple fact is that spawning a thread, a process, or setting up interrupt handlers, are more or less the same APIs (with varying levels of "things you're allowed to share" and "how simultaneous these things are"), but hooked up to different backends. what we wanna see is an API that allows a component, like wasi-threads to export a function that spawns threads, instead of baking it into component model. likewise we could have wasi-signals and wasi-popen using the same principle.

there are huge benefits to using "more or less the same API" instead of doing the same thing multiple times. like yeah, we could probably shove popens and interrupts into component model separately, but then you'd have to come up with 3 separate "how does this interact with the rest of the API", one for each of them, and if you overlook anything then things can go really wrong and you get unsoundness. having a model that describes what they're allowed to do and using the same model for all of them lets you get away with a lot more, even if it does take a little more upfront work.

does this make sense?

Dave Bakker (badeend) (Sep 25 2024 at 18:46):

In general, threading (and similarly: forking) is not "just" a function like any other. It affects many aspects of the runtime semantics.

Dave Bakker (badeend) (Sep 25 2024 at 18:47):

I recall there being a detailed blogpost about this in the context of WASM/WASI. But can find it right now

David Lloyd (Sep 25 2024 at 18:50):

I don't think GC would be terribly useful if it didn't allow cycles (at least I can't think of a GC'd language that would be able to use it if that were the case)

Soni L. (Sep 25 2024 at 18:51):

another use-case (and this one may be of interest to the serverless folks) is the ability to seamlessly use wasm in the database, with the embedder automatically handling the whole "sending the relevant core modules to the database" and stuff

should we stick that in the component model itself, like we're doing with threads?

Soni L. (Sep 25 2024 at 18:52):

it's more or less the same problem domain

Soni L. (Sep 25 2024 at 18:52):

David Lloyd said:

I don't think GC would be terribly useful if it didn't allow cycles (at least I can't think of a GC'd language that would be able to use it if that were the case)

(erlang/elixir)

Soni L. (Sep 25 2024 at 18:56):

Soni L. said:

another use-case (and this one may be of interest to the serverless folks) is the ability to seamlessly use wasm in the database, with the embedder automatically handling the whole "sending the relevant core modules to the database" and stuff

should we stick that in the component model itself, like we're doing with threads?

and here's the thing - we think wasm should be supporting such use-cases. not via "stick an API for each use-case into the component model specification (or some extension)" but "provide an API for the general class of these use-cases".

Dave Bakker (badeend) (Sep 25 2024 at 19:01):

As Chris said above; Feel free to write up a proposal for a generic mechanism that unifies threading and "sending the relevant core modules to the database and stuff"

Last updated: Nov 22 2024 at 17:03 UTC