rfcs Signal handling

Originally filed at https://github.com/rust-lang/rust/issues/11203

This involves filling out libnative/io/mod.rs, but this is also a very tricky issue. Right now the API is wrapped around what libuv provided for us, but that may not be the best API to have.

Dealing with signals is always an incredibly tricky topic, and here's the ideas for what should possibly happen:

on linux (maybe android?) signalfd should be used for everything
on windows, basically just do whatever libuv does and pray that everything works
on everything else, we're going to have to resort to sigaction. I believe that the best way to deal with this is libuv's trick of a self-looping pipe (the signal handler writes the signal onto a pipe which is read in the "event loop"). This will certainly involve some trickiness.

It has also been brought up that there are primitives like sigwait on unixes which can be used to just block a thread when waiting for "some group of signals", but the API which we have created for signals cannot wrap this functionality. We could add a similar function for libgreen/libnative, but I personally don't think it's worth it. It is worth some discussion, however.

Nov 12 '15 19:11 steveklabnik

There is the chan-signal crate, which can be used today to listen to signals safely on a channel. It uses the "spin up a thread and wait" approach, so it may not be applicable in all scenarios. The API probably could use some work too.

Nov 12 '15 20:11 BurntSushi

fwiw, I see no mention here of "thread-directed" signals. IMHO, it's reasonable to not support them as a first pass (they're a totally different thing than process-directed signals), but worth at least being explicit about what's in scope.

As an example of what these are: let's say I do a mmap of a file and try to read from it but another process has truncated the file so the page I'm reading is no longer valid. A SIGBUS is generated and directed to the thread doing the read. It can't be handled by some other thread using signalfd or the like.

Likewise, SIGFPE, SIGSEGV, SIGILL, SIGPIPE, and anything done with pthread_kill/pthread_sigqueue. The last case is sometimes used as a mechanism for CPU / wall clock profiling tools or thread cancellation.

May 17 '16 17:05 scottlamb

signalfd should be used for everything.

AFAIK, signalfd cannot be used for everything.

May 27 '16 10:05 glandium

Relevant article, which also mentions Rust: https://ldpreload.com/blog/signalfd-is-useless

Aug 16 '16 21:08 oconnor663

is there still interest in this being part of rust std? Or, is it expected that client libraries will fill the gap for now/future

Oct 10 '16 00:10 DrRibosome

I believe we'd still be interested in it being part of the standard library, but we'd like the API to be hashed out in a third party crate first.

Oct 10 '16 05:10 sfackler

Any updates on this?
Personally it's no hurries or anything.

I just feel like I should add my comment here supporting including this in the STD. It's a basic feature every language should have. Especially since the current way of doing it requires FFI or a crate which probably also does FFI, which feels like a dirty hack.