The write of websocket.Conn gets blocked if called from different thread when blocking_mode is true

[IamSanjid]

I am not sure if I am using it wrong, but using default httpz config, blocking_mode is true, after receiving websocket.Conn when I try to write to it from a different thread, it blocks that thread and never properly writes it meaning the Client never receives the message, did a litttle investigation call to std.posix.writev hangs, so I think I am using it the wrong way? Window's WriteFile API doesn't support different thread "write"(s)? or it's the Zig's standard library at fault? Any suggestions would be helpful.

[karlseguin]

If I'm being honest, these window issues have been my bane. See karlseguin/websocket.zig#46 for another example. For one, I have no means of reproducing them.

It doesn't sound like you're doing anything wrong. And I'm unsure if my libraries are wrong, or if Zig's windows abstractions are wrong.

I believe my use of writev is correct, or at least, it does the same thing as Zig'd stdlib: https://github.com/ziglang/zig/blob/2e2927735d26fc6047343f0c620f20e9048ebaa5/lib/std/net.zig#L1884

I find the windows documentation frustrating - I don't see it mention anything about thread-safety, although non-official sources seem to indicate that it is thread-safe. Anyways, *websocket.Conn.write itself uses a mutex to ensure a single thread writes at any given time.

The best thing to do is to strip out httpz and websocket.zig and see if the problem can be reproduced using Zig's standard library - as we did with the linked issue above.