Signal is sometimes not delivered on Unix platforms, causing deadlocks in tokio-process

[christophebiocca]

MVCE: https://github.com/christophebiocca/tokio-process-deadlock-example

Originally filed as alexcrichton/tokio-process#42

Unfortunately trying to not use tokio-process at all fails to recreate the issue, so something more subtle is going on: https://github.com/christophebiocca/tokio-process-deadlock-example/tree/repro-attempt-without-tokio-process

Arch Linux
rustc 1.26.1 (827013a31 2018-05-25)
cargo 1.26.0 (0e7c5a931 2018-04-06)

The reason I think tokio-signal is responsible for the bug is that the following printf trace shows a pipe write never causing a wakeup:

[tokio-process:src/unix.rs:Child::poll_exit]: We polled sigchld for 13284
[tokio-process:src/unix.rs:try_wait_process]: LIBC says we should wait more for 13284
[tokio-process:src/lib.rs:Child/Future::poll]: POLLING_STATUS for Child: Ok(NotReady)
I am spawned process #1
[tokio-signal:src/unix.rs:handler]: PIPE SIGNALLING RESULT: Ok(1)

See full details in alexcrichton/tokio-process#42 (comment)

[alexcrichton]

I'm gonna close in favor of alexcrichton/tokio-process#42 and discuss there, I'm not 100% sure that it's an issue here and may be an issue with the process bindings as well