Re: SBCL Fibers proposal

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

Noting the "currently" in there, I was going to suggest exposing a
*fiber-trampoline* variable that can establish a dynamic environment (e.g.
to make it look like a normal thread, with the debugger) in all fibers
created (which probably needs a whole lot more stack), but that doesn't
affect already running fibers. The lack of debugging / interactivity by
default makes me uncomfortable, but I guess there is no way around that.

GC:
- I wonder if conservativeness becomes increasingly problematic with more
fiber stacks, or if we luck out by having the extra conservative roots
mostly the same.
- To see how much linear scaling with the number stacks is, a composite
benchmark that involves GC would be nice.

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