Need for a better error handling

[0Karakurt0]

Right now there are a lot of segmentation faults if you make a mistake in handling io_uring. Like, for example, forget to io_uring_queue_init() before io_uring_get_sqe().
I know that this is a low-level interface that requires more considerations, and I suspect that I catched more of them than usual because of learning and a bug caused by garbage collector, but I still think that catching a segmentation fault should be considered for a python library.

[YoSTEALTH]

I am rewriting this library in Zig but have to wait a bit longer because there are many limitations/complexity, but soon hoping to have a proper stable release.

[0Karakurt0]

Why...?

[YoSTEALTH]

Liburing itself doesn't seem to work well with FFI languages since io_uring is low level. The Second you add FFI middleman in the mix io_uring losses most of its advantages.

This library was working just fine last time I coded it. Every time FFI library released a new version there was more bugs related to FFI and I felt like I spent more time finding their bugs then coding this library itself.

Currently there is limitation in Zig because their translate-c doesn't translate all the liburing C code to zig properly. But overall most of the code works so its worth using it. Also zig is fast, memory safe, ... overall a better option then using C(not memory safe).

I started writing this library in Zig + cPython (C) that took a while (had to learn zig + cPython at same time) and it works but the code complexity is too much and it will be a pain to maintain.

Just the other day I found https://pyoz.dev/ its a way better option. So currently coding using that.

Its a struggle between Stability, Speed & Complexity.

Python ctypes gives you stability but losses speed, cffi in the middle, Cython gives you speed but breaks your library with complexity (bugs)