Proposal: move Mio-signals into Mio

[Thomasdezeeuw]

The Mio-signals crate provides a cross-platform way to handle process signals without having to setup signal handlers. Instead you can receive a mio::Event, which tells you to check the Signals type for received process signals. And all of this can be done without spawning any additional threads. On OSes with kqueue(2) it uses EVFILT_SIGNAL, on Linux signalfd(2). The current set of supported signals is slim, SIGINT, SIGTERM and SIGQUIT, but that could be expanded.

One disadvantage is that it doesn't have Windows support, supporting is being tracked in Thomasdezeeuw/mio-signals#4. Current idea is to use a NamedPipe, but I never got around to testing that idea.

Source: https://github.com/Thomasdezeeuw/mio-signals
Docs: https://docs.rs/mio-signals/0.1.2/mio_signals/

[pfmooney]

This is definitely an interesting proposal. I've been looking at wiring up event ports in Mio (for illumos, where epoll works, but event ports is the "more native" OS facility). Like kqueue, it supports port notifications for signals. In addition to that, it can subscribe to events from timers, message queues, and filesystem events. If Mio-signal is to be rolled into Mio, it might be a good opportunity to look at the Registry interfaces could be expanded (internally) to make non-fd cases like those easier. It would be nice to avoid having to chain the Poll resources when adding unsafe resources (which are not represented by a RawFd). Keeping that within mio could be an appropriate boundary for the abstraction.

Thoughts?

[Thomasdezeeuw]

This is definitely an interesting proposal. I've been looking at wiring up event ports in Mio (for illumos, where epoll works, but event ports is the "more native" OS facility). Like kqueue, it supports port notifications for signals. In addition to that, it can subscribe to events from timers, message queues, and filesystem events. If Mio-signal is to be rolled into Mio, it might be a good opportunity to look at the Registry interfaces could be expanded (internally) to make non-fd cases like those easier. It would be nice to avoid having to chain the Poll resources when adding unsafe resources (which are not represented by a RawFd). Keeping that within mio could be an appropriate boundary for the abstraction.

Thoughts?

I'm open to expanding Registry interface. But since I don't know much about illumos event ports and any API it might need, it's hard to give any more feedback than that.

[Thomasdezeeuw]

Since Mio-signals still hasn't got Windows support I'm going to close this. It can live in a separate crate for now and can always be added after v1.