example/fd compile error on windows: std.posix.fd_t is of type windows.HANDLE *anyopaque on windows instead of i32 on linux.

[0x546F6D]

install
└─ install fs
   └─ zig build-exe fs Debug native 1 errors
src\http\router.zig:271:31: error: expected type '*anyopaque', found 'comptime_int'
                        .fd = -1,
                              ^~
referenced by:
    serve_fs_dir__anon_6036: src\http\router.zig:284:14
    main: examples\fs\main.zig:60:28

Not sure what is the workaround here since fd is then compared to -1 on src\http\router.zig:70

            if (fd <= -1) {
                try provision.context.respond(.{
                    .status = .@"Not Found",
                    .mime = Mime.HTML,
                    .body = "File Not Found",
                });
                return;
            }

On a side note, what is the current status of zzz for windows?
I have tried the other examples and, as reported previously, the cpu usage is indeed very high, and the example executables like benchmark, stop responding after a minute on my machine. Furthermore, except for the basic executable, none of the other executables seem to respond properly on this windows 11 machine with neither firefox nor chrome.

Taking the benchmark executable for example. After starting it, clicking on "click here to go to hi", or writing directly in the address bar 'http://localhost:9862/hi/user' does update the location in the address bar of the browser, but most of the time, it only refreshes the home page, as can be seen in the debug logs:

debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 0 - recv triggered
debug(zzz/http/server): 0 - parsing header
info(zzz/http/server): 0 - "GET /" Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 0 - send triggered
debug(zzz/http/server): 0 - sent length: 420
debug(zzz/http/server): 0 - queueing a new recv
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 0 - recv triggered
debug(zzz/http/server): 0 - parsing header
info(zzz/http/server): 0 - "GET /" Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 0 - send triggered
debug(zzz/http/server): 0 - sent length: 420
debug(zzz/http/server): 0 - queueing a new recv
debug(tardy/runtime): Wait for I/O: true

Switching back and forth between 'localhost' and '127.0.0.1' in the address bar can help you go to the other page. However, if you do succeed to land on 'http://localhost:9862/hi/user', then benchmark sometimes gets stuck on displaying the 'user' name even after submitting another one (like 'qwerty'), or after changing it directly in the address bar to 'http://localhost:9862/hi/qwerty'. Setting std_option.log_level to .debug shows that it always default to 'GET /hi/user' no matter what I submit or write in the address bar.

debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 1 - recv triggered
debug(zzz/http/server): 1 - parsing header
info(zzz/http/server): 1 - "GET /hi/user" Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 1 - send triggered
debug(zzz/http/server): 1 - sent length: 537
debug(zzz/http/server): 1 - queueing a new recv
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 1 - recv triggered
debug(zzz/http/server): 1 - parsing header
info(zzz/http/server): 1 - "GET /hi/user" Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
debug(tardy/runtime): Wait for I/O: true
debug(zzz/http/server): 1 - send triggered
debug(zzz/http/server): 1 - sent length: 537
debug(zzz/http/server): 1 - queueing a new recv

Same thing happens when clicking on 'click to go home!': the location in the address bar changes back to 'http://127.0.0.1:9862', but the browser still displays the '/hi/user' page unless you switch back to 'localhost' instead of '127.0.0.1'.

[mookums]

Hi @0x546F6D, I'll take a look at this tomorrow morning but which version are you currently using? Is this on v0.2.0?

[0x546F6D]

I am sorry, I did not pay careful attention to the installation instruction and did zig fetch #main instead of #v0.2.0.
benchmark.exe and sse.exe seem to behave properly on this windows 11 machine when using v0.2.0, with the only issue being the high cpu usage reported previously.

The '*anyopaque'/'comptime_int' issue for fd still remains in v0.2.0:

install
└─ install fs
   └─ zig build-exe fs Debug native 1 errors
src\http\router.zig:154:31: error: expected type '*anyopaque', found 'comptime_int'
                        .fd = -1,
                              ^~
referenced by:
    serve_fs_dir__anon_5963: src\http\router.zig:168:14
    main: examples\fs\main.zig:60:28
    remaining reference traces hidden; use '-freference-trace' to see all reference traces

[mookums]

Hi!

1. The issue with the serve_fs_dir trying to compare the fd with -1 is now fixed. I forgot to use the Cross versions of these methods but it should be fixed now. (d1adbd0)

2. The issue with the stalling of the connections (the issue with the URLs not changing) was because I did a partial rework of how data is moved around (to reduce latency and get a little more performance out of it) and I forgot to readd the clearing of the headers. This is also fixed here (39bb96a)

3. The high CPU usage is Windows is (See: Idle CPU usage + Failure of io_uring backend #14). I've created a tracking issue (Tracking: IOCP for Windows tardy#4) in Tardy regarding IOCP to bring a Async I/O to the Windows platform. Currently, it uses the busy_loop fallback which basically loops 24/7 waiting for data to arrive.

Feel free to try out the main branch and let me know if you continue to run into those issues!

[0x546F6D]

Hi Mookums, thanks a lot for the fast reply. I pulled the latest commits up to 2f9808b and here are my observations:

1. the issue is gone, example/fs now compiles on windows.
2. benchmark.exe, sse.exe and fs.exe still behave as described in my 1st post. They do not respond properly like they do with v0.2.0.
3. I wish you good luck, my zig knowledge over even programming knowledge in general is too far below yours to even comprehend what needs to be accomplished there :)
4. the unix example does not compile on windows anymore since the latest commit (fix(windows): remove unix sockets on windows):

install
└─ install unix
   └─ zig build-exe unix Debug native 1 errors
examples\unix\main.zig:49:37: error: no field named 'unix' in union 'http.server.Server(.{ .plain = {} }).BindOptions__union_6728'
                try server.bind(.{ .unix = "/tmp/zzz.sock" });
                                    ^~~~
src\http\server.zig:198:25: note: union declared here
            .windows => union(enum) {
                        ^~~~~
referenced by:
    main: examples\unix\main.zig:52:10
    callMain: C:\Users\thomas.collet\scoop\apps\zig\0.13.0\lib\std\start.zig:524:32

But that's probably to be expected, so I just commented the corresponding add_example line in build.zig.
I am sorry to have mixed up all those issues in one place. I should have opened another issue for 2. So you can close this one as completed since the main reason to open it in the 1st place has already been fixed with Tardy Cross.

[mookums]

No problem! I'm glad you submitted an issue, helps me get around to looking at different parts. I didn't know that that weird issue was still there BUT it should now be fixed! (07fbe2c). This happened because we were writing into an invalid buffer (that we cleared) instead of requesting a new write area from the zero-copy buffer.

I also added a compilation flag for the Unix example so it won't get built on Windows. (64c1a90) 😃

[0x546F6D]

Everything seems fine now with the latest version, congrats :)
I just have a couple questions concerning fs.exe:

• to be served the static/index.html file, writing "localhost:9862/static" in the address bar is not enough, right? We need to write "localhost:9862/static/index.html"
• "localhost:9862/static/index.html" is served as "Content-Type = application/octet-stream" instead of "Content-Type = text/html", so the index.html file is being downloaded instead of being displayed in the browser. Is that the expected behavior?

[mookums]

1. Yes, that's currently the expected outcome with the serve_fs_dir. I will likely be reworking a lot of the Route stuff soon so stuff might change but that's to be determined.

2. That was fixed last night (3fc7e58), I think you caught me in the middle of some changes. I'm going to close this issue now just because we are going a little off-topic regarding the title. If you run into any other issues or have any other questions, feel free to create a new one 👍