Signal handling

[steveklabnik]

Originally filed at rust-lang/rust#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.

[BurntSushi]

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.

[scottlamb]

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.

[glandium]

signalfd should be used for everything.

AFAIK, signalfd cannot be used for everything.

[oconnor663]

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

[DrRibosome]

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

[sfackler]

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.

[jD91mZM2]

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.

[william20111]

Is there a go to 3rd party crate for dealing with signals? or is it only using libc & unsafe currently?

[droundy]

I use the ctrlc crate, which is not a complete solution, but is moving towards handling more than just SIGINT.

[0xpr03]

currently https://github.com/swizard0/rust-simple-signal seems like the way to go

[esemeniuc]

would love to see some progress on this

[zaddok]

Definitely would love to see progress. Seems like it should be standard to me.