4 ms·

Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagshi

Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces: https://github.com/WebAssembly/WASI/tree/main/wasip2 https://github.com/WebAssembly/WASI/tree/main/wasip2 This is what people are building on, in the upstream, and in the bytecode alliance You're absolutely right about embeddings being varied, but the standard existing enforces the expectations around a core set of these, and then the carving out of embeddings to support different use cases is a welcome and intended consequence. WASI started as closer to POSIX now, but there is a spectacular opportunity to not repeat some mistakes of the past, so some of those opportunities are taken where they make sense/won't cause too much disruption to people building in support.

DaiPlusPlus 2y ago
> the flagship feature there is async without function coloring Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place. I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications. …but if WASI is simply adding more options without taking anything away then my point above is moot :)
- danpalmer 2y ago
  Further to this, my (very basic) understanding is that the actual threading implementation will be left up to the integrator, so some implementations may not actually implement any concurrency (a little like the Python GIL in a way), while others may implement real concurrency, therefore meaning that subtle threading bugs could be introduced that wouldn't be seen until you run in other environments.
- hardwaresofton 2y ago
  > Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place. Correct -- note that the async implementation does not address parallelism (i.e. threading) -- it's a language +/- runtime level distinction. The overhead is already in the languages that choose to support -- tokio in rust, asyncio in python, etc etc. For those that don't want to opt in, they can keep to synchronous functions + threads (once WASI threads are reimagined, working and stable!) You can actually solve this problem with both multiple stacks and a continuation based approach, with different tradeoffs. > I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications. > > …but if WASI is simply adding more options without taking anything away then my point above is moot :) Didn't take it as such! The ability to avoid function coloring does not block the implementations of high-threads/high-memory applications, once an approach to threading is fully reconsidered. And adding more options while keeping existing workflows in place is definitely the goal (and probably the only reasonable path to non-trivial adoption...). How to do it is quite involved, but there are really smart people thinking very hard about it and trying to find a cross-language optimal approach. For example, see the explainer for Async: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md https://github.com/WebAssembly/component-model/blob/main/des... There are many corners (and much follow up discussion), but it's shaping up to be a pretty good interface, and widely implementable for many languages (Rust and JS efforts are underway, more will come with time and effort!).
pjmlp 2y ago
CORBA, DCOM, RMI, .NET Remoting, Tcl Agents,... but this time it will be better.
- RALaBarge 2y ago
  It isn't the fault of the group that suggests and standardizes protocols, it is everyone thinking they are smarter and they can do it better is the problem.
  - pjmlp 2y ago
    Especially when ignoring prior art, and why it eventually went away.
    - mardifoufs 2y ago
      How is Wasm ignoring prior art? Like what mistakes have been made that were already known about before? Genuinely curious.

DaiPlusPlus 2y ago

> the flagship feature there is async without function coloring Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place. I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications. …but if WASI is simply adding more options without taking anything away then my point above is moot :)

danpalmer 2y ago
Further to this, my (very basic) understanding is that the actual threading implementation will be left up to the integrator, so some implementations may not actually implement any concurrency (a little like the Python GIL in a way), while others may implement real concurrency, therefore meaning that subtle threading bugs could be introduced that wouldn't be seen until you run in other environments.
hardwaresofton 2y ago
> Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place. Correct -- note that the async implementation does not address parallelism (i.e. threading) -- it's a language +/- runtime level distinction. The overhead is already in the languages that choose to support -- tokio in rust, asyncio in python, etc etc. For those that don't want to opt in, they can keep to synchronous functions + threads (once WASI threads are reimagined, working and stable!) You can actually solve this problem with both multiple stacks and a continuation based approach, with different tradeoffs. > I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications. > > …but if WASI is simply adding more options without taking anything away then my point above is moot :) Didn't take it as such! The ability to avoid function coloring does not block the implementations of high-threads/high-memory applications, once an approach to threading is fully reconsidered. And adding more options while keeping existing workflows in place is definitely the goal (and probably the only reasonable path to non-trivial adoption...). How to do it is quite involved, but there are really smart people thinking very hard about it and trying to find a cross-language optimal approach. For example, see the explainer for Async: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md https://github.com/WebAssembly/component-model/blob/main/des... There are many corners (and much follow up discussion), but it's shaping up to be a pretty good interface, and widely implementable for many languages (Rust and JS efforts are underway, more will come with time and effort!).

pjmlp 2y ago

CORBA, DCOM, RMI, .NET Remoting, Tcl Agents,... but this time it will be better.

RALaBarge 2y ago
It isn't the fault of the group that suggests and standardizes protocols, it is everyone thinking they are smarter and they can do it better is the problem.
- pjmlp 2y ago
  Especially when ignoring prior art, and why it eventually went away.
  - mardifoufs 2y ago
    How is Wasm ignoring prior art? Like what mistakes have been made that were already known about before? Genuinely curious.