chibi-scheme
chibi-scheme copied to clipboard
ashinn
Provide delimited continuations
Implement delimited continuations on top of the existing primitive %call/cc. Space leaks are prevented through a new primitive %abort.
See issue #885.
Thanks for working on this, this is awesome!
I guess a more optimal implementation would use continuation marks (in Chibi basically a pointer to a stack object and an offset) and slice only up until that mark, but this is OK for now.
My primary concern is the huge amount of code added to init-7.scm, which is supposed to be tiny. How much of this can be moved into SRFI 226?
Thanks for working on this, this is awesome!
Thank you! Chibi may not be the fastest implementation on the planet, but thanks to the clear code, hacking and improving it is fun.
I guess a more optimal implementation would use continuation marks (in Chibi basically a pointer to a stack object and an offset) and slice only up until that mark, but this is OK for now.
As Chibi's call/cc primitive copies the whole stack, the code for the dynamic-wind-aware call-with-current-continuation in my patch may actually be an efficiency improvement because the call stack is effectively cut in slices.
What would be an improvement if Chibi's VM offered a primitive to call a thunk in a given continuation. Once this is in place, I could eliminate the %call-with-current-continuation hack.
My primary concern is the huge amount of code added to init-7.scm, which is supposed to be tiny. How much of this can be moved into SRFI 226?
The previous init-7.scm exported dynamic-wind (and a dynamic-wind-aware call/cc). As I didn't want to remove this, I had to put substantial parts into init-7.scm. If you really want to keep it small, removing dynamic-wind and implementing call-with-current-continuation in (srfi 226) seems the way to go. (The library (scheme base) can then import call-with-current-continuation from (srfi 226) and not from (chibi).)
Hmm... the ctak benchmark is almost 4x slower with this. Currently we copy the whole stack, but in practice the stack is rarely large, and the copy is just an optimized C loop (actually we could tune it more).
Hmm... the ctak benchmark is almost 4x slower with this. Currently we copy the whole stack, but in practice the stack is rarely large, and the copy is just an optimized C loop (actually we could tune it more).
Some of the slow-down is because of the %call-with-current-continuation hack that is currently necessary because there is no primitive (VM instruction) calling a thunk in a continuation (i.e. throwing away the current continuation, replacing it by the given one and then calling the thunk given this new call stack. Adding such a VM instruction looks simple.
The new code in init-7.scm was written for clarity and correctness (and to mimic the code in the sample implementation of SRFI 226). One can probably fine-tune it and expand procedures/records by hand so that Chibi is able to run it faster.
But this exists - it's
SEXP_OP_RESUMECC.
Good. What are the parameters that this bytecode expects? And can it be called directly from the user code?
Sorry, lost track of this. It just takes a stack object (e.g. as saved by call/cc) and replaces the current stack with it.
The bytecode is compiled into the final-resumer global in sexp_init_eval_context_bytecodes. Every time you run call/cc it makes a closure using this bytecode and the saved stack.
This does not implement the continuation marks feature of SRFI 226, if I understand correctly? Is this an inherent limitation of this approach or could they also be added (perhaps in a separate PR)?
