async is stackless coroutines, less powerful than stackful ones and vastly less powerful than first-class continuations, which is what call/cc provides, but also way more performant as there’s basically zero memory management overhead…
Where do the call stacks for the different async tasks live and how are they allocated?
That’s the neat thing: They aren’t, futures don’t contain their stack the compiler infers, statically, what they will need, and put that in a struct. As said, practically zero memory overhead.
First-class continuations aren’t evil they’re naughty, dirty only if used when not actually making anything clearer. Delimited continuations are actually a generalisation of call/cc and arguably way easier to think about, it’s just that call/cc predates their discovery and made it into standard lisp and scheme, where is that Felleisen paper, here: 1988. 13 years after scheme, 28 after lisp. longjmp/setjmp exist since at least System V and C89 according to the linux man pages, I guess they implemented it to implement lisp in. It’s just that C is about the worst language to use when you’re writing anything involving continuations, everything gets very complicated very fast, and not because continuations are involved but because you have no gc, no nothing, to support you.
Scheme has call/cc but standard Lisp (i.e. Common Lisp) doesn’t. Hmm, Rust async is like C++20 coroutines, so they can only yield from the outermost level of the task etc.? (Added: C Protothreads also come to mind). That sounds constraining even compared to the very lightweight Forth multitaskers of the 1970s. Python’s original generators were like that, but they fixed them later to be stackful coroutines. ~And do you mean there is something like a jump table in the async task, going to every possible yield point in the task, such as any asynchronous i/o call? That could be larger than a stack frame, am I missing something?~ (No that wouldn’t be needed, oops).
Setjmp/longjmp in C had some predecessor with a different name, that went all the way back to early Unix, way before C89. It was routinely used for error handling in C programs.
I’ve implemented Lisp (without call/cc) in C using longjmp to handle catch/throw. It wasn’t bad. Emacs Lisp also works like that.
I had been pretty sure that delimited continuations were strictly less powerful than first-class continuations, but I’ll look at the paper you linked.
I found some search hits saying you were supposed to implement signal handlers in Rust by setting a flag in the handler and then checking it manually all through the program. Even C lets you avoid that! It sounds painful, especially when there can be asynchronous exceptions such as arithmetic error traps (SIGFPE) that you want to treat sanely. But I haven’t looked at any Rust code that does stuff like that yet.
Hmm, I wonder if it’s feasible to use the Boehm garbage collection method in Rust, where the unsafe region is limited to the GC itself. Of course it would use pointer reversal to avoid unbounded stack growth. Of course I don’t know if it’s feasible to do that in Ada either.
async is stackless coroutines, less powerful than stackful ones and vastly less powerful than first-class continuations, which is what call/cc provides, but also way more performant as there’s basically zero memory management overhead…
That’s the neat thing: They aren’t, futures don’t contain their stack the compiler infers, statically, what they will need, and put that in a struct. As said, practically zero memory overhead.
First-class continuations aren’t evil they’re naughty, dirty only if used when not actually making anything clearer. Delimited continuations are actually a generalisation of call/cc and arguably way easier to think about, it’s just that call/cc predates their discovery and made it into standard lisp and scheme, where is that Felleisen paper, here: 1988. 13 years after scheme, 28 after lisp. longjmp/setjmp exist since at least System V and C89 according to the linux man pages, I guess they implemented it to implement lisp in. It’s just that C is about the worst language to use when you’re writing anything involving continuations, everything gets very complicated very fast, and not because continuations are involved but because you have no gc, no nothing, to support you.
Scheme has call/cc but standard Lisp (i.e. Common Lisp) doesn’t. Hmm, Rust async is like C++20 coroutines, so they can only yield from the outermost level of the task etc.? (Added: C Protothreads also come to mind). That sounds constraining even compared to the very lightweight Forth multitaskers of the 1970s. Python’s original generators were like that, but they fixed them later to be stackful coroutines. ~
And do you mean there is something like a jump table in the async task, going to every possible yield point in the task, such as any asynchronous i/o call? That could be larger than a stack frame, am I missing something?~ (No that wouldn’t be needed, oops).Setjmp/longjmp in C had some predecessor with a different name, that went all the way back to early Unix, way before C89. It was routinely used for error handling in C programs.
I’ve implemented Lisp (without call/cc) in C using longjmp to handle catch/throw. It wasn’t bad. Emacs Lisp also works like that.
I had been pretty sure that delimited continuations were strictly less powerful than first-class continuations, but I’ll look at the paper you linked.
I found some search hits saying you were supposed to implement signal handlers in Rust by setting a flag in the handler and then checking it manually all through the program. Even C lets you avoid that! It sounds painful, especially when there can be asynchronous exceptions such as arithmetic error traps (SIGFPE) that you want to treat sanely. But I haven’t looked at any Rust code that does stuff like that yet.
Hmm, I wonder if it’s feasible to use the Boehm garbage collection method in Rust, where the unsafe region is limited to the GC itself. Of course it would use pointer reversal to avoid unbounded stack growth. Of course I don’t know if it’s feasible to do that in Ada either.