implement signal handling

[alexcrichton]

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.

[alexcrichton]

Nominating.

[pnkfelix]

Assigning P-high, not 1.0.

[aturon]

cc me. I'm interested in working on this one.

[l0kod]

It would be great to be able to handle signals per task. This way we could send interrupt events to running tasks (e.g. to exit a blocking syscall).

Maybe a channel-like interface could allow to extend the OS-specific signal types with custom types/objects.

[l0kod]

Maybe a channel-like interface could allow to extend the OS-specific signal types with custom types/objects.

This could be an interesting abstraction of sigqueue.

[l0kod]

About signal receiving, a nice signalfd implementation could return a Signal struct wrapping an IoHandle<Fd> (cf. #19169) which could create a Receiver (with event()) usable with select!.

Signal could then expose SigInfo structs through an Iterator interface.

[l0kod]

cc Safe async/reentrant closure

[steveklabnik]

Pretty sure this would go through the RFC process these days, as it's pretty huge, so moving over there rust-lang/rfcs#1368