• Dmitry Olshansky (39/39) Oct 05 vibe.d-lite is an experimental alternative to the classic vibe.d,
• Kagamin (7/7) Oct 09 ```
• Dmitry Olshansky (3/10) Oct 10 This just checks if lpCompletionKey is in fact negative integer.
• Kagamin (2/2) Oct 17 I mean under ip32 lpCompletionKey is uint, and when you cast it
• Dmitry Olshansky (3/5) Oct 17 Good point. Though 32bit Windows is not the target I’d care about

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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:
```d
           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

Kagamin <spam here.lot> writes:

```
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.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.

Kagamin <spam here.lot> writes:

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

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.