Poor interactions with SIGCHLD-using projects

[mathstuf]

Describe the bug
I have a project that uses wait-timeout to check the timeout of some commands that are executed. By some printf debugging (unless there's some way to run tarpaulin under gdb), it seems that the SIGCHLD handler in wait-timeout is not being executed at all. Tarpaulin should chain off to any already installed signal handlers (if at all possible). Alternatively, it could be that something goes wrong when installing wait-timeout's signal handler?

Alternatively, maybe some way to disable interposition on SIGCHLD handler could be done?

To Reproduce
A simple example wasn't doing it, but the crate in question is here.

Expected behavior
Already installed SIGCHLD handlers should work.

[xd009642]

Have you tried --forward as a CLI arg, it forwards unexpected signals to the test process. I was considering making it default but I didn't know if it would break certain things

[mathstuf]

Ah, I had missed that flag. Trying now, thanks.

[mathstuf]

Hrm. Alas, that doesn't seem to resolve it for me. The odd thing is that the underlying crate which actually does the work is fine. It's when it's all driven from other threads and such using Tokio to manage communications via a Unix socket and other event sources that things end up going south.

[jrray]

I am facing a similar problem with a project that uses tokio::process::Command, which currently relies on SIGCHLD to get woken up. The subprocess exits but the parent process (my test) never stops waiting for the child process. Using --forward doesn't help.

There is some talk of removing the use of SIGCHLD here.

[xd009642]

I'd generally say now --engine llvm is potentially a solution the only issue is the llvm coverage instrumentation doesn't really handle threads or spawned processes well so results can differ from run-to-run. A lot has gone into tarpaulin since last comment so just wondering if things have changed for anyone?