Mastodawn

May 5, 2025

Hmm. Now that I have a working "generic" #signal handling in #poser, I'd like to optimize a bit by picking up @david_chisnall's suggestion to use #kqueue for the job if available. Would have a clear advantage: No need to fiddle with the signal mask around every call to #kevent.

I still had the doubt whether a signal delivered via kqueue would still remain pending when it is just blocked, so I wrote some little test code and the unfortunate answer is: yes. Unfortunate because I want my library code to restore everything as it was found (signal mask and handlers) on exit, but I certainly don't want a batch of spurious signals handled when unblocking them.

Kind of obvious solution: Set the signals temporarily to ignored when unblocking them, as shown in the screenshot. Now I have the next doubt: Is it guaranteed to have pending signals delivered instantly when unblocking them? 🤔

Ok, I forgot about restoring the previous state, cause I already broke this when implementing the generic signal handling via flags. And restoring everything to default must be good enough. Then, using #kqueue was kind of easy. Just this one weirdness that I'm not allowed to ignore #SIGCHLD, so I have to block this instead ... anyone has any idea why?

Still thinking whether I should also add support for #signalfd ... unfortunately different semantics, for that I should (according to its manpage) *block* signals, not ignore them. But maybe I should do some tests there as well.

Show thread

Felix Palmen

I think I'll "go #kqueue all the way" now, by also using it for providing my #timers if available. The current implementation multiplexes them on top of #setitimer, that's the portable variant that will stay as a fallback, but with kqueue, there's no need to have all these #SIGALRM generated, and I can avoid the slight imprecision by multiplexing in userspace 😎