Zig Version
0.13.0
Steps to Reproduce and Observed Behavior
Hello,
I've been trying to have a discussion over what I'm thinking can be a problem while using the std.posix.kevent(...) function in the Zig Standard Library.
The reviewed code is the same in version 0.13.0 and master:
https://github.com/ziglang/zig/blob/master/lib/std/posix.zig#L4480
I'm about to start some C to Zig translation of some production C library to give us, our company, some future choice on whether we have to change our programing language. So I've been looking inside the Zig Standard Library to check what is done with kqueue and kevent and to know how much we'd have to adapt the C code.
The std.posix.kevent function code seems to be blocking with a while(true) loop and a continue on EINTR.
Our production C code is using this EINTR error, but if translating to Zig, we cannot do that check since that std.posix.kevent call is hiding that error inside the while(true) { ... continue .. } loop.
kqueue and kevent are functions part of kernel event notification mechanism, and they are made so that the developer using them are not blocked by using timeouts, or by using the error code to further process some other pieces of code not to block the greater scheme of these events.
I'm thinking this loop and continue are too low level at this point in the Zig Standard Library, and that it is not empowering the developer with enough choice.
I don't particularly know how to fix this, but it seems like an issue to have and while(true) at this point of the Zig code.
Some context:
I've been using FreeBSD, and some C library that's using kqueue and kevent. This library is part of some production code, and it's working totally fine. As a reference, we've been reading kqueue(2) manual to create that library that is proprietary code.
In this C library, we are using the kevent to check if we've got some TCP data to read from the sockets we're monitoring, and we are checking the kevent return to known how many sockets have got data awaiting to be read, and also we are checking errno to check if the error is not EINTR, and if it's not it has to stop and get out with an error propagated up. Our loops around these kevent calls are the farther from these calls so it gets us some time to do some other processing and not to be blocked.
Expected Behavior
To be able to catch the EINTR error up in the Zig code using std.posix.kevent maybe adding an error case in the KEventError, like Interrupted, so that the while(true) is removed from this function not to block the events mechanism.
Zig Version
0.13.0
Steps to Reproduce and Observed Behavior
Hello,
I've been trying to have a discussion over what I'm thinking can be a problem while using the
std.posix.kevent(...)function in the Zig Standard Library.The reviewed code is the same in version 0.13.0 and master:
https://github.com/ziglang/zig/blob/master/lib/std/posix.zig#L4480
I'm about to start some C to Zig translation of some production C library to give us, our company, some future choice on whether we have to change our programing language. So I've been looking inside the Zig Standard Library to check what is done with
kqueueandkeventand to know how much we'd have to adapt the C code.The
std.posix.keventfunction code seems to be blocking with awhile(true)loop and a continue onEINTR.Our production C code is using this
EINTRerror, but if translating to Zig, we cannot do that check since thatstd.posix.keventcall is hiding that error inside thewhile(true) { ... continue .. }loop.kqueueandkeventare functions part of kernel event notification mechanism, and they are made so that the developer using them are not blocked by using timeouts, or by using the error code to further process some other pieces of code not to block the greater scheme of these events.I'm thinking this loop and continue are too low level at this point in the Zig Standard Library, and that it is not empowering the developer with enough choice.
I don't particularly know how to fix this, but it seems like an issue to have and
while(true)at this point of the Zig code.Some context:
I've been using FreeBSD, and some C library that's using
kqueueandkevent. This library is part of some production code, and it's working totally fine. As a reference, we've been reading kqueue(2) manual to create that library that is proprietary code.In this C library, we are using the
keventto check if we've got some TCP data to read from the sockets we're monitoring, and we are checking thekeventreturn to known how many sockets have got data awaiting to be read, and also we are checkingerrnoto check if the error is notEINTR, and if it's not it has to stop and get out with an error propagated up. Our loops around thesekeventcalls are the farther from these calls so it gets us some time to do some other processing and not to be blocked.Expected Behavior
To be able to catch the
EINTRerror up in the Zig code usingstd.posix.keventmaybe adding an error case in theKEventError, likeInterrupted, so that thewhile(true)is removed from this function not to block the events mechanism.