Re: SBCL Fibers proposal

On Mon, Mar 2, 2026 at 1:42 PM Michał "phoe" Herda <[email protected]> wrote:

> W dniu 2026-03-01 14:57, Anthony Green napisał(a):
>
> 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/
>
>
> One more question: does SB-DEBUG:PRINT-BACKTRACE work correctly and
> consistently across fibers?
>

Once again, thank you for directing me to a gap!    I've made some changes,
and everything seems to be working now.

When inside a running fiber, (sb-debug:print-backtrace) works. The fiber's
control stack is the active stack on the carrier thread, so the normal
debugger machinery sees it directly. You get the same output as you would
in a regular thread. frame-down stops at fiber_run_and_finish, which is the
absolute bottom of a fiber's stack, so you won't walk off into carrier
internals.

A pattern I use in some of my other projects is to add a signal handler (3)
to print backtraces for all threads -- just like in the JVM.  I do this by
iterating through the threads and using interrupt-thread to run
print-backtrace in the context of each thread.   For fibers, where stack
space may be limited, I've added the ability to print a fiber backtrace
from outside of the fiber: (sb-debug:print-fiber-backtrace
some-suspended-fiber).

This rebinds the debugger's stack-bounds checks to the fiber's control
stack, extracts the frame pointer and return address from the fiber-switch
save area, and then delegates to the same print-backtrace code.  So now, in
my own use case (kill -3), after dumping all threads, iterate through the
fibers, calling print-fiber-backtrace.

I've updated the document on my blog, and added a link to the git commit
history on the blog so you can easiy see what changed.

AG

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