Re: Coroutines, goroutines

(copying Kartik privately as well for feedback, who might have general comments or opinions on the interface)
I looked at the branch briefly (but didn’t try it) and it definitely looks like the right thing. Kartik’s interface if I remember correctly was heavily inspired by Lua coroutines. I suggested that he copy the CMU CL green thread scheduling code for the actual implementation which he then ported to arm64 for the conference lightning talk (an all-nighter hack session the day before!!). As far as I know, he didn’t work on it further, but someone else at ELS 25 picked it up and continued it but never ended up submitting it either.
A note: since you’re using an LLM anyway, it might be easy enough to port to the other supported architectures, which would be even better. It doesn’t necessarily have to work or be rigorously tested, but since your instance already has the context anyway it might be much easier for you to put it in than someone else to add it on later.
A small thing: I do have a slight preference for using Lisp assembler for the assembly routines if possible (or putting it into VOPs like in the green threading implementation), since they require less OS specific hacks for doing things and make redefinition a bit easier to hack on later if something changes.
Thank you for doing this work! The documentation is also very helpful. When you submit it in a complete state with tests and all, I’ll volunteer to try to do a more thorough review and help you land the feature.
On Thursday, February 26, 2026, 11:40 AM, Anthony Green <[email protected]> wrote:

On Thu, Feb 26, 2026 at 3:32 AM Scott L. Burson <[email protected]> wrote:

What size stacks are you allocating for the fibers?

256k is the default, but you can change it when you create your fiber.
I'm not quite done with it yet, but, as you can see from the kneejerk reaction on the list, some people have an automatic bias against the use of AI assistance without letting the quality of the work speak for itself.  I added cooperative threading to Guile scheme almost exactly 30 years ago, and I would love to help bring this to SBCL today.   I'll submit it for review once it's done, but feel free to follow along on my branch in the meantime and offer your feedback there.
Thanks,AG
 

-- Scott



On Wed, Feb 25, 2026 at 10:55 PM Scott L. Burson <[email protected]> wrote:

Hi all,
I tried to contact Kartik Singh directly about this, but got a "you are not an authorized sender" bounce.  Since Kartik is on this list, I assume this will get through.  The discussion is likely of wider interest anyway.
I've seen the video of Kartik's lightning talk at ELS 2024 titled "Proof of Concept: Coroutines in SBCL".  He ported over some old CMUCL threading support, without the scheduler.  But the work is still sitting in a GitHub fork and doesn't seem to have gone anywhere.  I would like to encourage, support, and if needed, participate in getting it ready for general use and into SBCL, at least as a contrib module, if that's possible.
I do think it should have a scheduler, though.  I will take the liberty of quoting Pascal Costanza (from a message to the Common Lisp Pro mailing list, [email protected], 2025-12-28):

Something that is very relevant to understand in the Go context: Go channels are not based on pthreads, but they are based around Go’s own tasking model (which of course are in turn based on pthreads, but’s not that relevant). Go’s tasking model is an alternative to previous async programming models, where async code and sync code had to be written in different programming styles - that made such code very difficult to write, read and refactor. (I believe https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ is the text that made that insight popular.)
In Go, async code looks exactly the same as sync code, and you don’t even have to think about that distinction anymore. This is achieved by ensuring that all potentially blocking operations are effectively not blocking, but instead play nicely with the work-stealing scheduler that handles Go’s tasking model. So, for example, if a task tries to take a lock on a mutex, and that is currently not possible, the task gets swapped out and replaced by a different task that can continue its execution. This integration exists for all kinds of potentially blocking operations, including channels.
With pthreads, a lock / mailbox / etc. that blocks can have the corresponding pthread replaced by another one, but that is much more expensive. Go’s tasks are handled completely in user space, not in kernel space. (And work stealing gives a number of very beneficial guarantees as well.)
This nuance may or may not matter in your application, but it’s worth pointing out nonetheless.
It would be really nice if Common Lisp had this as well, in place of a pthreads-based model, because it would solve a lot of issues in a very elegant way...

I do see people on Hacker News, Reddit, and elsewhere saying that they would love to use CL, but it needs to have lightweight threads in order to work for their use cases.
I wonder as well if it might be possible, while such code is being touched, to work in firstclass delimited continuations.  These would be for people writing solvers, such as Screamer.  (Yes, I'm aware of CL-Cont; but it heap-allocates every continuation.)  Something to think about, anyway.
So — what do the SBCL team think about this?  Is it something you would support, or even help out with?
And for Kartik — how much work do you think remains to get coroutine functionality into a generally usable state?
-- Scott
_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel



_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel