#timerfd

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2025-05-24

@jhx Hopefully 😎 I just verified it still builds and works on #illumos (#solaris descendant) as well.

A linux build without specific options should show using #epoll, #signalfd and #timerfd here 😉

Quick smoke-test of swad-0.11 on OpenIndiana
Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2025-05-14

Now that #swad 0.7 is released, it's time to prepare a new release of #poser, my own lib supporting #services on #POSIX systems, following a #reactor with #threadpool design.

During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. #select) to auto-detected support for #kqueue, #epoll, #eventports, #signalfd and #timerfd (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a #dictionary using nested hashtables internally, or #async tasks mimicking the async/await pattern known from e.g, #csharp. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).

I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....

And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔

Stay tuned, something will come here, maybe helping you to write a nice service in plain #C 😎:

github.com/Zirias/poser

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2025-05-08

@Toasterson @astade Hehe, I'm surprised it detects and uses #signalfd and #timerfd, which I expected to be Linux-exclusive interfaces ...

First attempt running swad on OpenIndiana
Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2025-05-08

@Toasterson @astade I'm downloading an #OpenIndiana image right now, we will see.

For Linux, I now have support for #epoll (fd events), and additionally #signalfd and #timerfd. On the BSD's that have #kqueue, it covers all these aspects. So, little question here: Are there any solaris / #illumos APIs specifically for signal handling and individual timers I should look into? Or should I stick to classic async handlers (signals) and setitimer (timers) on that platform, and just have a look at /dev/poll?

Client Info

Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst