vibe.d-lite v0.1.0 powered by photon
Sönke Ludwig
sludwig at outerproduct.org
Fri Sep 19 08:01:35 UTC 2025
> 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?
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).
> 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? 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.
> 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.
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.
Anyway, it's great to see this progress, as well as the performance numbers!
More information about the Digitalmars-d-announce
mailing list