- The most underappreciated part of this design is the transparent integration: existing SBCL primitives (grab-mutex, condition-wait, sleep) auto-detect fiber context and yield cooperatively instead of blocking the carrier thread. Existing code runs inside fibers without modification. This is extremely hard to get right, especially around GC interactions and binding stack state.
Java's Project Loom solved an almost identical problem for the JVM -- platform threads too expensive, event-driven too complex -- and landed on the same architecture: lightweight virtual threads that intercept blocking JDK calls transparently. The comparison is instructive because Loom also had to deal with thread-local state (ThreadLocal pinning), GC coordination, and the cooperative scheduling footgun where CPU-heavy work starves other virtual threads on the carrier.
That last point is the one concern I'd have at scale. A fiber doing 50ms of compute without yielding blocks everything else on its carrier. Go handles this with automatic yield point insertion at function prologues. Not clear how SBCL could do the same without compiler-level changes to the code generator.
by mark_l_watson
1 subcomments
- I am excited by the proposal and early work. SBCL Common Lisp is my second most used programming language - glad to see useful extensions. Most of my recent experiments with SBCL involve tooling to be called by LLMs/agents and high speed tooling to provide LLMs/agents with better long term memory and context. Fibers will be useful for most of that work.
by smallstepforman
5 subcomments
- 256Kb stack per Fiber is still insane overhead compared to Actors. I guess if we survey programming community, I’d guesstimate that less than 2% of devs even know what the Actor model is, and an even smaller percentage have actually used it in production.
Any program that has at least one concurrent task that runs on a thread (naturally they’ll be more than one) is a perfect reason to switch to Actor programming model.
Even a simple print() function can see performance boost from running on a 2nd core. There is a lot of backround work to print text (parsing font metrics, indexing screen buffers, preparing scene graphs etc) and its really inefficient to block your main application while doing all this work while background cores sit idle. Yet most programmers dont know about this performance boost. Sad state of our education and the industry.
by nothrabannosir
2 subcomments
- I strongly recommend having a look at the mailing list to get some context:
https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAF...
and
https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAC...
This will certainly speak to some people taking part in some of the more controversial discussions taking place on HN recently, to put it mildly.
by nesarkvechnep
0 subcomment
- Every move in the concurrency direction is good but I really wanted to see preemptive scheduling and Erlang-like processes.
by HexDecOctBin
1 subcomments
- Is there a similar document for the memory arena feature? I tried searching the official documentation, but found scant references and no instructions on how and when to use it.
by matthewfcarlson
1 subcomments
- I personally like the name fiber better than green threads. But everywhere I’ve worked in user space cooperative threads, it’s always been green threads.
by theParadox42
0 subcomment
- I really thought this was gonna be a sick material science paper. Still cool though
- Serious question - I thought LLMs were bad at balancing parentheses?
- SBCL - Steel Bank Common Lisp
- They should be called Anthony Green Threads.
Seriously though, great to see.
Hacker News