Re: continuation passing in Emacs vs. JUST-THIS-ONE

[Jim Porter]

On 4/17/2023 12:50 PM, Stefan Monnier wrote:
> > This whole thread seems to echo the difference between "stackless" and
> > "stackful" coroutines discussed in
> > https://nullprogram.com/blog/2019/03/10/ by the author of emacs-aio,
> > with generator-style rewriting corresponding to stackless and threads
> > to "stackful".  So when you say "save as much as threads do", I'm not
> > clear if you're talking about rewriting code to essentially create a
> > heap allocated version of the same information that a thread has in
> > the form of its stack, or something more limited like some particular
> > set of special bindings.
>
> Indeed to "save as much as threads do" we'd have to essentially create
> a heap allocated version of the same info.
> [ I don't think that's what we want.  ]

I think this subthread is about two different aspects, which is probably 
due in part to me not distinguishing the two enough initially; one of 
the reasons I'd find it useful to "save as much as threads do" is so 
that there could be a path towards packaging tasks up to run on another 
thread, and for them to eventually have enough context that we could run 
multiple packaged tasks *concurrently*. That's separate from a 
more-general asynchronous programming library (though they would likely 
interact with one another).

Javascript might be a useful analogue here, since it too was originally 
single-threaded with an event loop, and more concurrency features were 
added in later. Similarly to "modern" JS, we could have async/await 
constructs that (primarily) work on the main thread, plus something 
similar to web workers, which operate as mostly-independent threads that 
you can communicate with via messages.