Thread overview
vibe.d-lite v0.2.0 with Windows support
Oct 09
Kagamin
3 days ago
Kagamin
October 05

vibe.d-lite is an experimental alternative to the classic vibe.d, that reimplements vibe-core package on top of Photon fiber scheduler and event loop.

https://github.com/DmitryOlshansky/photon

Since it was suggested that Windows support won't be easy, I found it very compelling to just try and make it work. I kind of like the end result which is based on Windows IOCP and integrates overlapped I/O for files with IOCP and passes them through for regular threads.

https://code.dlang.org/packages/vibe-d-light
https://code.dlang.org/packages/vibe-http-light

Pick latest v0.2.x for Windows support.

Among other changes runTask now spawns task on the same thread to match what vibe.d ecosystem expects. To run your server in mulithreaded mode some incantation like the following is required:

          runWorkerTaskDist(() nothrow { // runWorkerTaskDist spawns a fiber per core
		try {
			auto settings = new HTTPServerSettings;
			settings.port = 8080;
			settings.bindAddresses = ["127.0.0.1"];
			settings.options = HTTPServerOption.reusePort; // this is important

			auto routes = new URLRouter;
			routes.get("/", staticTemplate!"home.dt");
			//...
			routes.rebuild();

			auto httpListener = listenHTTP(settings, routes);
		} catch (Exception e) assert(false, e.msg);
            });

The whole thing is not that well tested but unittests pass and basic HTTP server works.

At the moment it's for the brave souls that seek faster vibe.d and are willing to help me out (by filing bugs for instance) to make it production ready.

--
Dmitry Olshansky

October 09
if (cast(long)e.lpCompletionKey < 0) {
	fiber = fileWaiters[cast(int)-cast(long)e.lpCompletionKey];
}

Heh, if you didn't assume LP64, this would be another unsigned integer bug.

October 10

On Thursday, 9 October 2025 at 09:27:09 UTC, Kagamin wrote:

>
if (cast(long)e.lpCompletionKey < 0) {
	fiber = fileWaiters[cast(int)-cast(long)e.lpCompletionKey];
}

Heh, if you didn't assume LP64, this would be another unsigned integer bug.

This just checks if lpCompletionKey is in fact negative integer. Overflow would happen if we manage to open 2^31 files.

3 days ago

I mean under ip32 lpCompletionKey is uint, and when you cast it to long, it's never negative.

3 days ago

On Friday, 17 October 2025 at 16:08:54 UTC, Kagamin wrote:

>

I mean under ip32 lpCompletionKey is uint, and when you cast it to long, it's never negative.

Good point. Though 32bit Windows is not the target I’d care about at this time.