Re: SBCL Fibers proposal

Thank you for taking the time to review.

On Wed, Mar 4, 2026 at 4:20 AM Gábor Melis <[email protected]> wrote:

> - 2.6 "and a parked carrier is woken": Is there always one?
>

No, there isn't.  This should actually say "and a parked carrier is woken
if one exists" or similar.


> - 2.7 "finish-fibers joins all carrier threads and returns results":
> Should be "joins all fibers in the group"?
>

This was poorly worded.   It should say "finish-fibers blocks until all
fibers in the group have completed, then returns their results."   The
mechanism used to implement this is to join the carriers (which exit when
all fibers in the group have finished), but this is an implementation
detail.


>
> - 8.3: How can waiting on mutexes be efficient? As far as I can tell, it
> falls under "waiting list walk" in maintenance.
>

Yes, there's room for improvement here.  A per-mutex fiber wait queue would
allow us to avoid scanning a list.  This is an implementation detail that's
on my TODO list.


>
> - 12:
>   Unlike THREAD-JOIN, FIBER-JOIN only returns one return value. Why?
>

I will correct this oversight.


>   The assumption is that unwinding from a fiber can happen on ERRORs only.
> This is mostly true because
>   - no catch tags established around the user-provided function;
>   - catch tags from other fibers or the carrier thread are not visible
>   - lexical non-local exits are invalid.
>
>   That leaves SERIOUS-CONDITIONs. How can they be dealt with?
>

Good question!  I think these should be fiber errors, except
for sb-sys:interactive-interrupt, which we can propagate to the carrier.


>
>   Does the interactive debugger work with fibers? Can we provide restarts
> like ABORT, RETURN-VALUE, RETURN-NOTHING as in the OS thread case?
>

Currently, if users want interactive debugging, they should establish their
own handler-bind/invoke-debugger in the fiber's function. Restarts like
ABORT would work within the fiber's own catch/block scope.


>
> - 13.4 (WHEN (AND *CURRENT-FIBER* *CURRENT-SCHEDULER*) ...): Special
> variable access (2) on the hot path?
>

Looking at this again, there's no code path where (AND *CURRENT-FIBER* (NOT
*CURRENT-SCHEDULER*)), so we can just check *CURRENT-FIBER*.



> - 14: Why not compare to OS threads with smaller stack sizes?
>


I'm building a repo with reproducible benchmarks, and I'll definitely
include that.


Thanks again,

AG



>
>
> On Sun, 1 Mar 2026 at 14:59, Anthony Green <[email protected]> wrote:
>
>> My fibers patches aren't ready to be submitted yet, but I've posted
>> the proposal, including many details and some benchmark results here:
>> https://atgreen.github.io/repl-yell/posts/sbcl-fibers/
>>
>> If it's easier to provide feedback on the list, I could post the entire
>> text here.
>>
>> Thanks,
>> AG
>> _______________________________________________
>> 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