vibe.d-lite v0.1.0 powered by photon

[Dmitry Olshansky]

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 ;)