Add support for POSIX per-process timers to the standard library

[jp39]

This change adds support for POSIX timers to the standard library.

It adds the required structure and enum definitions to call the timer_* API on linux. It also fixes a couple of issues I identified with signal mask handling. In addition to the timer_* API, this change also adds definitions for sigsuspend, sigemptyset, sigfillset, sigaddset, sigdelset and sigismember.

This change allows calling the libc version of the API if the target links with the C library.

Thank you.

[jp39]

Note on portability : After playing with a bunch of different Operating Systems, I could test that API on both Linux and FreeBSD. Although POSIX is in the name, this API is part of the POSIX real-time extension, and as such, the functions are optional.

Disappointingly, I discovered that this API is not available on Darwin, nor on DragonFlyBSD. I read somewhere that it's not supported on OpenBSD either, I have not checked the other OSes.

However, on linux this API predates the timerfd API and allows delivering notifications using signals and threads instead of file descriptors.

[kprotty]

Are posix timers useful for the standard library? Userspace implementations of timers are almost always faster due to not having to go through syscalls to update the Timer state or check for expiry. They can also block using more efficient schemes as opposed to signals. Applications which use timers in combination with multiplexed fd waiting (e.g. epoll/kqueue) like Golang and Rust Tokio use their own timer implementation for similar reasons.

[jp39]

@kprotty, I totally get the point you're trying to make, although I would argue that just because it's not the optimal way of implementing an event loop doesn't mean that no-one has any good reason to use that API.

Also, the timerfd API, which is less portable than Posix timers, and which is not a userspace implementation, is already in the standard library. If we're being coherent, there's not reason not to consider Posix timers for inclusion.

[kprotty]

I was more so trying to figure out a use case for posix timers, as I'm still not sure. Genuinely curious not only for justification purposes.

The standard library is trying to not add stuff that it doesn't directly use or that many users don't use as a general rule. There's some leftover parts like timerfd that don't fit this rule but have just stayed there just because / for no particular reason. I think its fair to say that a PR to remove it would be considered, but since the entire stdlib will be reworked (eventually) such a PR isn't too helpful ATM.

[jp39]

Well in that case I totally understand. Fell free to drop the MR if you think it won’t be usefull to anyone.

However, the first few patches in this MR are more here for correctness of the existing code and are not directly related to the posix timer API. I think they should still be considered for inclusion.

Also, is there a document somewhere that defines what the standard library should be ? If i understand your point correctly, zig is not aiming to provide a standard library that covers everything that the libc already provides, but rather a bare minimum interface that every user will be encouraged to use ? If that’s the direction that zig is trying to take, it leaves me wondering where bindings for standard APIs like this one should live if not in zig’s std library ?

[andrewrk]

Closing due to

• all CI checks failing
• conflicts with master branch
• lack of activity

Please feel free to continue this effort in a new pull request against latest master branch commit.