More ligthweight waiting for signals

[Michal 'vorner' Vaner]

I've noticed in #4 that the waiting for signals on unix is more heavy-weight than it probably deserves. The signal-hook::iterator::Signals is the most comfortable interface for application usage, as it allows conveniently blocking on an iterator and can handle multiple distinct signals at once, but it is also quite a bit of code that needs to be compiled (it can be turned off by a feature) and needs a separate thread for the blocking. It doesn't seem this crate would need any kind of multiple signals support and blocking is probably even an anti-feature.

I would send a pull request with doing something more lightweight, but I want to discuss design first.

• The easiest way would be to replace the Signals with pipe. This would allow removing the feature flag and cutting down on the amount of code being compiled.
• The next step would be to use some FD-thing (pipe/socket) that is async ready and starting a task instead of thread. But that would probably mean the code between unix and windows would diverge a bit further.
• Or, alternatively, is the wakeup mechanism inside smol async-signal-safe, or does it use mutexes or something like that? If it is safe, it would be possible to just notify from within the signal handler itself. That would need a bit of unsafe (promise that it's really async-signal-safe), but would allow going directly to signal-hook-registry and not creating further file descriptors.

What do you think would be the best way forward?

[Taiki Endo]

Thanks for the suggestion!

• The easiest way would be to replace the Signals with pipe. This would allow removing the feature flag and cutting down on the amount of code being compiled.

I haven't investigated how much the compile time changes depending on whether the feature is enabled, but this seems to make sense.

• The next step would be to use some FD-thing (pipe/socket) that is async ready and starting a task instead of thread. But that would probably mean the code between unix and windows would diverge a bit further.
• Or, alternatively, is the wakeup mechanism inside smol async-signal-safe, or does it use mutexes or something like that? If it is safe, it would be possible to just notify from within the signal handler itself. That would need a bit of unsafe (promise that it's really async-signal-safe), but would allow going directly to signal-hook-registry and not creating further file descriptors.

cc @stjepang What do you think about this? (I'm not familiar enough to answer/review this.)

[tinywombat765]

Not sure if this would impact this issue but i recently had my PR merged that made signal-hook-async-std only use async-io, thereby making it usable with smol with no extra async dependacies.

Edit: and futures-lite. That change is in version 0.2.1.

vorner/signal-hook#91

[Dominik Stolz]

Another alternative to signals might by pidfds. There already exists a crate which uses them with async-io: async-pidfd

[Michal 'vorner' Vaner]

signal-hook-async-std would be more heavyweight than what's there right now (at least in the amount of dependencies).

pidfd is probably linux specific, non-portable.