3 ms·

What do stackfull coroutines have to do with cooperative vs non-cooperative concurrency? They’re entirely orthogonal problems. JavaScript absolutely does want

What do stackfull coroutines have to do with cooperative vs non-cooperative concurrency? They’re entirely orthogonal problems. JavaScript absolutely does want stackfull coroutines (even if they’re not called coroutines, but just async stacks). That why chrome has so much magic inside it to reassemble async stack traces for exceptions. But it has to do that via all manner of complex bookkeeping and jiggery-pokery, which is often broken by libraries doing clever things. Having async functionality built on top of cooperative coroutines, all sharing a single system thread, would make async stacktraces trivial to produce accurately, and make it substantially easier to debug highly interwoven async code.

ameliaquining 4y ago
The connection is that you can inefficiently simulate stackful coroutines with non-cooperative concurrency. Just give each coroutine its own OS thread, and block whenever the coroutine yields. It's slow and not a good way to build real systems, but the fact that it's possible at all means that libraries have to be designed to be able to handle it (e.g., that if they call into user code, it might yield the thread) and so not assume for correctness that their code will keep running in the order they control without interruption. JavaScript wasn't designed to support non-cooperative concurrency, and so a lot of existing code does assume that it's safe to, e.g., mutate global state in a way that other code doesn't expect or can't handle, run some operation, and then put the global state back how it was. Chrome's async stack traces don't undermine this because they are only for debugging; they can't in any way affect control flow. Stackful coroutines would break this assumption, the same way preemptive multithreading would. You can argue that the language should have included these features from the beginning, but it didn't, and changing it now would mess up the ecosystem.
- avianlyric 4y ago
  What on earth are you talking about. Why would anyone want to inefficiency simulate stackfull co-routines using system threads? And what does underlying engine design have to do with the JavaScript spec? Additionally why do you think anyone is advocating for the use of a single system thread per co-routine in a discussion about Java virtual threads, a technology does the literal opposite? There’s nothing preventing anyone from creating a JavaScript engine that simulates async JavaScript using stackful cooperative co-routines, all operating in a single shared system thread. Perfectly upholding the existing JS thread model, but substantially reducing the bookkeeping needed to produce useful stack traces.

ameliaquining 4y ago

The connection is that you can inefficiently simulate stackful coroutines with non-cooperative concurrency. Just give each coroutine its own OS thread, and block whenever the coroutine yields. It's slow and not a good way to build real systems, but the fact that it's possible at all means that libraries have to be designed to be able to handle it (e.g., that if they call into user code, it might yield the thread) and so not assume for correctness that their code will keep running in the order they control without interruption. JavaScript wasn't designed to support non-cooperative concurrency, and so a lot of existing code does assume that it's safe to, e.g., mutate global state in a way that other code doesn't expect or can't handle, run some operation, and then put the global state back how it was. Chrome's async stack traces don't undermine this because they are only for debugging; they can't in any way affect control flow. Stackful coroutines would break this assumption, the same way preemptive multithreading would. You can argue that the language should have included these features from the beginning, but it didn't, and changing it now would mess up the ecosystem.

avianlyric 4y ago
What on earth are you talking about. Why would anyone want to inefficiency simulate stackfull co-routines using system threads? And what does underlying engine design have to do with the JavaScript spec? Additionally why do you think anyone is advocating for the use of a single system thread per co-routine in a discussion about Java virtual threads, a technology does the literal opposite? There’s nothing preventing anyone from creating a JavaScript engine that simulates async JavaScript using stackful cooperative co-routines, all operating in a single shared system thread. Perfectly upholding the existing JS thread model, but substantially reducing the bookkeeping needed to produce useful stack traces.