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