ws support

[221V]

this is Websocket support + (optional) PubSub for zzz for zig 0.14.1
also error fixed in deps

tardy-org/secsock#10

tardy-org/tardy#33

[221V]

just add 4th ws example - file upload via ws, with queue and pause-resume feature
also fix frame buffer
:)

[0xtempest]

let's get this merged?

[221V]

let's get this merged?

maybe, I do not know
looks like original author working now onto other big things, and this one thing waiting new zig version(s)

---

I make all what I can, ws (as is) works well for me :)
(maybe something can be optimised, but I do not know what places and how)

feel free to clone and try to use my fork branch
https://github.com/221V/zzz/tree/zig-0.14

good luck :)
happy new year :)

[0xtempest]

I cloned all tardy repos, got all versions working with 0.15.2, merged ws support. Added a bunch of features to sqlt like connection pooling, prepared statement support, etc.

You'll be able to find them all here: https://github.com/PersonaEnterprises

[mookums]

@0xtempest @221V

Been a lot busier than usual these past few months. I am willing to take on maintainers to keep this going. Feel free to email me at muki@muki.ggif you're interested and we can keep these projects going.

[bernardassan]

@221V, can you upgrade this PR to Zig 0.15.2? I want to review and consider merging this. Or @0xtempest you can PR your branch if @221V doesn't have the time to do that.

I will upgrade secsock to 0.15.2 soon so that everything goes smoothly.

[bernardassan]

@0xtempest can you PR your sqlt changes also at https://github.com/tardy-org/sqlt for review and merging

[221V]

@221V, can you upgrade this PR to Zig 0.15.2?

no, I stay at zig 0.14.1

but I am working onto update for 0.14.1 -- fix + perf upgrade

[221V]

@mookums , @0xtempest , @bernardassan guys, please help --
I dont understand is that memleaks or tardy runtime normal/special workflow ?

on my ws_example_1 -- got more and more used RAM (RES in HTOP) when just reload that simple page with ws ..
more and more RAM used and not frees ..

I was try to detect and to fix but .. I am newbie in system programming, here needs more deeper understanding that I have now ..

https://github.com/221V/zzz/commits/zig-0.14/
221V/tardy@4e0e33d
221V@5f26fb4
221V@dc8adeb

that all not helps ((
I have no idea how to fix that myself ((

upd. next fixes biggest memleak on ws (looks like exists one more but tiny memleak) --
221V@17eed2a
http example(s) has no memleak, ws example(s) still have memleak, too less but still have..

[bernardassan]

There have been a few complaints around Zzz memory usage. I haven't thoroughly investigated this yet, but I think it mainly has to do with how we are currently managing global resources like frames and server state.

For frames, I think using the new Io.async defer cancel semantics should help, and for server state, being explicit about our memory management strategy, like the use of arenas and properly freeing them where appropriate (at the end of a request lifecycle), should help.

I have created #68 to track this. I will allocate some time over the coming weeks to look into this, as an issue with memory usage is also noted in #65

[221V]

I got working files upload via ws with httpz
https://github.com/221V/http.zig/blob/zig-0.14/examples_ws/04_websocket.zig

still not understand how to get working bearssl with httpz,
but in other hand with zz needs to calculate and set by hands stack size for every task..
that can be a bit headache..
I'd like to use heap-based fibers instead
https://github.com/221V/fibers_zig
so now will use fibers + httpz + nginx in real project
httpz is stable, and zzz has some memleak issue that I cannot understand and fix..
tiny moment in some place((
I made that was possible..
I will not touch zzz for new year or few years..

ok, anyway, thank you)

[bernardassan]

Your sentiments are understandable and reasonable. I have implemented Coroutine frame size hinting for users in tardy-org/tardy#46, so users know the appropriate stack size to use in debug mode; release mode is always smaller, and there are the auto & std Stack options, which are usually reasonable stack sizes.

The memory leaks and idle CPU usage (busy-loop) issues are now the top priority for the next release. After that, I will take up WebSocket support myself.

In the next few releases, Tardy and Zzz are going to be more production-ready. Hopefully, you might consider reusing Zzz again in the future. It was nice to have you here.