Stream: wasi

Topic: component model threading system questions


view this post on Zulip Soni L. (Sep 25 2024 at 17:50):

why is threading limited to threads?

view this post on Zulip Soni L. (Sep 25 2024 at 18:03):

why are threads provided by component model?

view this post on Zulip 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?

view this post on Zulip Soni L. (Sep 25 2024 at 18:04):

(or even like popen or async-signal safety)

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip Soni L. (Sep 25 2024 at 18:15):

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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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:

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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)

view this post on Zulip 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?

view this post on Zulip Soni L. (Sep 25 2024 at 18:52):

it's more or less the same problem domain

view this post on Zulip 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)

view this post on Zulip 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".

view this post on Zulip 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: Dec 23 2024 at 12:05 UTC