As a Zig developer with one of the more popular HTTP server libraries around (http.zig), this is impressive and good use of comptime and (good) abuse of Zig's anytype. I'm looking forward to learning from the codebase.
But, it's very slow. A quick test shows Sinatra is about 2x faster. Maybe I'm in the minority, but I feel that a primary reason to give up a GC is for performance.
Like many http server implementations in Zig, this is a wrapper around `std.http.Server`. `std.http.Server` only exists as a mechanism to test the `std.http.Client` (which is needed for things like, downloading packages). So `std.http.Server` isn't built to be fast, secure or robust.
I believe you _can_ get keepalive working with `std.http.Server`, but it seems like Tokamak isn't using it that way. The implementation is a thread-per-connection. Those are the two most obvious issues specific to this implementation.
But I believe the bulk of the issues relate to `std.http.Server`. It shouldn't be public/used.
Oh, I didn't know std.http.Server is not supposed to be used. I guess I could just use your project (as dependency) and that would fix that perf issue? And do a thread-pool and keep-alive, of course.
TBH perf was not my priority yet, I only wanted predictable memory usage and Zig was perfect choice for that (when compared to node.js).
This server assumes *all* clients are well behaved and standard compliant; it can and will deadlock if a client holds a connection open without sending a request.
Atop your readme, you point out that nginx or another reverse proxy should be used. Kudos for that.
As for performance, I'd be curious what gains you get using `std.http.Server` with keepalive and a threadpool. Possibly you can re-use your ThreadContext - having 1 per thread in the threadpool that you can re-using. `std.Thread.Pool` is also very poorly tuned for a large number of small batch jobs, but that's a place to start.
Hm, thanks for pointing that out. I need nginx for SSL anyway, so I was not even thinking about going raw :)
I'm wondering where exactly is the problem in the std.http.Server because it might be easy to fix. Maybe it's just that nobody cared yet... But 2x slower than Ruby sounds awful.
> Possibly you can re-use your ThreadContext
Yes, this is the idea, and extending the injector for request-scoped and thread-scoped dependencies.
Yeah, I'm with you, I thought this thing was just waiting for some "function colouring" behaviors to be ironed out in zig before it was to be polished. I guess comments from https://news.ycombinator.com/item?id=35991684 made me think this but it's good to have been informed that this in fact is not the case (and is closer to a com.sun.net.httpserver.HttpServer as a ref for us ole java folk)
But, it's very slow. A quick test shows Sinatra is about 2x faster. Maybe I'm in the minority, but I feel that a primary reason to give up a GC is for performance.