Use kqueue `EVFILT_SIGNAL` to support signals on BSD

[ids1024]

The fact that signals are only supported on Linux is currently one of the issues using Smithay on BSDs. It looks like it should be possible to implement this with kqueue instead of signalfd, though I'm not currently familiar with kqueue.

[ids1024]

I guess for this to work, Kqueue needs a method for registering things other than fds, and Poll would need BSD/macOS specific methods wrapping it?

EVFILT_SIGNAL messages are sent after normal signal handling, even for SIG_IGN signals. So if the signal is set to SIG_IGN this should provide the same behavior that signalfd offers. (This is why BSD doesn't have things like signalfd; they aren't needed when kqueue exists.)

Or technically it's possible to poll a kqueue or insert it in another kqueue. So that might work with the current API but isn't exactly elegant.

[elinorbgr]

I think an option would definitely be to handle signal handling in a way more tightly coupled to the internal Poll, like is currently done for timers.

Event sources provided in calloop are privileged, in that they can directly tap into the Poll logic, rather than only use the public API.

[ids1024]

Good point. This needn't result in any change to the public API (other than making the signal support available on BSD/macOS). It could be useful to have a public API for other kqueue filter types (seems handy for crate consumers targetting kqueue OSes).

Probably the awkward thing here is that subscribing to an EVFILT_SIGNAL won't block the signal. So we need to also use sigaction to ignore signals that would otherwise cause the process to terminate. This sort of global state is awkward, and could lead to inconsistent behavior with multiple event sources for the same signal. Or code outside calloop dealing with signal handlers. But I guess that shouldn't really happen, so it's not a problem as long as that isn't undefined behavior.

[notgull]

polling supports this via the Signal type.