Am 19.09.25 um 12:33 schrieb Dmitry Olshansky:
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.
Shouldn't it still be possible to set an "interrupted" flag somewhere
and let only the vibe-core-lite APIs throw? Low level C functions should
of course stay unaffected.
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?
It's more of a timeout pattern that I've seen multiple times, there are
certainly multiple (better) alternatives, but if compatibility with
existing code is the goal then this would still be important.
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.
Telling in what way? It's really quite simple, you can use plain D
threads as normal, or you can use task pools, either explicitly, or
through the default worker task pool using `runWorkerTask` or
`runWorkerTaskDist`. (Then there are also higher level concepts, such as
async, performInWorker or parallel(Unordered)Map)
Not everything is CPU bound and using threads "just because" doesn't
make sense either. This is especially true, because of low level race
conditions that require special care. D's shared/immutable helps with
that, but that also means that your whole application suddenly needs to
use shared/immutable when passing data between tasks.
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.
But TLS variables are always "globals" in the sense that they outlive
the scope that accesses them. A modification in one thread would
obviously not be visible in another thread, meaning that you may or may
not have a semantic connection when you access such a library
sequentially from multiple tasks.
And then there are said libraries that are not thread-safe at all, or
are bound to the thread where you initialize them. Or handles returned
from a library may be bound to the thread that created them. Dealing
with all of this just becomes needlessly complicated and error-prone,
especially if CPU cycles are not a concern.
By robbing the user the control over where a task spawns, you are also
forcing synchronization everywhere, which can quickly become more
expensive than any benefits you would gain from using multiple threads.
Finally, in the case of web applications, in my opinion the better
approach for using multiple CPU cores is *usually* by running multiple
*processes* in parallel, as opposed to multiple threads within a single
process. Of course, every application is different and there is no
one-size-fits-all approach.
