On Friday, 19 September 2025 at 08:01:35 UTC, Sönke Ludwig wrote:
So in the last couple of weeks I've been porting vibe-core,
vibe-stream, vibe-inet and vibe-http to:
I guess vibe-stream/-inet/-http just need to be adjusted due to
limitations of vibe-core-lite? Would it make sense to upstream
those in some way (`version (Have_vibe_core_lite)` if
necessary) to avoid diverging more than necessary?
I think stream/inet is just updating the deps to be “light”.
Maybe some Interruptible* change.
It would be interesting to have vibe-core-light / vibe-core
compatibility. Http had some less than minor changes but yes the
most changes are in core.
More broadly, it would be interesting how to best organize this
in a way that avoids code duplication as much as possible and
ensures that the APIs don't deviate (although vibe-core has
been very stable).
Agreed.
2. There is no Interruptible* mutexes, condvars or anything
photon doesn't support the notion and code that relies on
interrupt needs to be rethought (including some part of vibe.d
itself).
Is this a fundamental limitation, or could it be implemented in
the future?
The limitation is this - photon operates inside of syscall
wrappers, those are nothrow so if we get interrupted there is no
way to throw anything. Plus this could be deep in some C library,
not sure how exception would propagate but likely missing cleanup
in the C side.
I know interruption/cancellation is generally problematic to
get to work across platforms, but interruptible sleep() could
at least be implemented by waiting on an an event with timeout,
and I guess sleep() is the most important candidate to start
with.
Sleep is trivial but also kind of pointless, if you want to
interrupt why not wait on the event and trigger that?
5. Fibers are scheduled roughly to the least loaded cores so
all of LocalThis LocalThat are in fact SharedThis and
SharedThat, simplifying the whole thing and making it easier
to scale.
This is okay for `runWorkerTask`, but would be a fundamental
deviation from vibe-core's threading model. Having the basic
`runTask` schedule fibers on the calling thread is absolutely
critical if there is to be any kind of meaningful compatibility
with "non-lite" code.
I on the other hand imagine that it’s not. In year 2025 not
utilizing all of available cores is shameful. The fact that I had
to dig around to find how vibe.d is supposed to run on multiple
cores is telling.
In general, considering that TLS is the default in D, and also
considering that many libraries are either not thread-safe, or
explicitly thread-local, I think it's also the right default to
schedule thread-local and only schedule across multiple threads
in situations where CPU load is the guiding factor. But being
able to get rid of low-level synchronization can also be a big
performance win.
Most TLS using libs would work just fine as long as they are not
pretending to be “globals” and the whole program to be single
threaded. Say TLS random has thread-local state but there is no
problem with multiple fibers sharing this state nor any problem
that fibers in different threads do not “see” each other changes
to this state.
Anyway, it's great to see this progress, as well as the
performance numbers!
Yeah, but I still think there is potential to go faster ;)
