- It's interesting how some ideas very quickly start popping up everywhere at once. One of my colleagues was working on adding support for fibers to systemd for some time (and the PR was merged a few days ago[1]!). From my understanding, this model is really quite useful for programs like pid1 that cannot use threads.
[1]: https://github.com/systemd/systemd/pull/39771
by nasretdinov
0 subcomment
- Looks really interesting. I assume this suggests that ClickHouse is going to gradually switch to using this library for network and I/O, thus addressing the main weakness (in my mind) of C++ thread-per-connection servers, which is, they (surprisingly!) create too many threads and can't really handle more than, say, a thousand active connections at the same time. It mostly matters for async INSERTs in this case of course, not for SELECTs, although generally it applies to both.
by jeffreygoesto
2 subcomments
- Is this comparable to Sea star [0]?
[0] https://github.com/scylladb/seastar
- I've been doing this with something very similar in GNOME for years now. It also does io_uring, threadpool schedulers, workstealing, "pollable semaphores" (like IRIX), profiler integration, and makes fibers implemented as futures themselves.
https://github.com/GNOME/libdex/
- The `Cilk` angle is interesting. There’s still room for small runtimes focused just on fork/join recursion.
I’ve been working on one for C: https://github.com/xtellect/cactus
It’s narrower than Silk/SeaStar: continuation stealing for CPU-bound recursive code, not a general async I/O fiber runtime.
- Seems not exception safe when task switching during unwind.
- Looks like its using MinIO for the S3 benchmark, which is now archived. I wonder what they'll switch to (if anything)
- Play on Cilk?
- those who don't learn Erlang/Elixir are bound to reinvent the Erlang VM and OTP model.
by fleahunter
0 subcomment
- [flagged]
- [flagged]
by embirdating
0 subcomment
- [dead]
by stefantalpalaru
0 subcomment
- [dead]
by SeattleAntifa
0 subcomment
- [dead]
Hacker News