Re: Coroutines, goroutines

Check out the fibers branch of my sbcl fork.
https://github.com/atgreen/sbcl/tree/fibers
It is working, and I am hoping to submit this for review soon.   It just
needs a few more tweaks.

Some docs here:
https://github.com/atgreen/sbcl/blob/e106c1cbcaae98ec7893d68d1f39675d10b5d882/doc/manual/threading.texinfo#L275

AG


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
> <https://www.youtube.com/watch?v=S2nVKfYJykw> 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
> <https://gitlab.common-lisp.net/cl-cont/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