Re: SBCL Fibers proposal

> When it returns normally, the return value becomes the fiber's result 
> (retrievable via fiber-result). If it signals an unhandled error, the 
> condition object becomes the result instead.

This means that a fiber can't return a condition instance without 
causing confusion (not all conditions are errors, yadda yadda). Can 
FIBER-RESULT return two values, similar to IGNORE-ERRORS?

Re 2.4, does it mandate calling with a function object even if I want 
something to execute 5+ seconds from now? So it would be (FIBER-PARK 
(CONSTANTLY NIL) :TIMEOUT 5)?

Re 5.2, the title mentions no guard page, but the content mentions guard 
pages.

Re 5, I assume that it is impossible or nigh impossible to dynamically 
change the stack size of a process upon an overflow, BEAM-process-style 
- am I correct?

Re 9.4, what are the safety mechanisms during copying?

Re 12.2, that is just for errors; how does this handle (possibly 
invalid) non-local returns via RETURN-FROM and GO?

Re 13: is INTERRUPT-THREAD patched in any way?

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