Re: Coroutines, goroutines

On Wed, Feb 25, 2026 at 8:34 PM Anthony Green <[email protected]> wrote:

> 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.
>

Wow, great news!

I see you're using Claude Code, and you started ... yesterday!?  Wow,
that's freaky.  I'd love to see the transcript.

What size stacks are you allocating for the fibers?

-- 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
>> <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