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!
