[biorach]

> . A general thread of execution is just a sequence of continuations executed one after another.

you're using a definition of "thread" that is quite abstract and not at all what is generally meant by most people when discussing these things

> multiple lightweight threads map on an heavier weight thread like in Node

describing Node as implementing M:N threading, while correct in an abstract sense, is not really useful or again, how most people would describe it.

> A specialized async/await runtime is a bit different from the typical M:N runtime... but conceptually there isn't much difference.

sure, conceptually, but again, you're using definitions in a very idiosyncratic and abstract manner. Which is your right, but it's not very persuasive and it's out of touch with how most people talk about these things.

[gpderetta]

Well, technically Node is N:1. But concretely, what significant difference you see from a async/await runtime and threaded runtime, other than the former requiring yield points to be syntactically marked in code?

[biorach]

I find the developer experience is quite different. Which is actually quite important. In the async runtimes I am familiar with I find managing shared resources and locking much easier.

But maybe I'm missing something here. Do you know of an async runtime and a threaded runtime that do not have significant differences?

[gpderetta]

Take boost.asio: it is a generic event loop (that can run on one or more OS threads): on top of asio you can run old school manual continuation passing code, promise/future based code, async code using C++20 coroutines (or a macro hack), or more classically multithreaded code using boost.context. You can write the same logical code in any style and the transformation is fairly mechanical.