select! macro don't seems to work with blocking tasks

[taorepoara]

I'm working on a CLI tool and two crates helped me a lot to make it really interesting:

• tokio to handle async tasks
• rustyline to build a custom terminal interface

They both work perfectly separatly, but I'm trying to make them work together and it stopped working as I espected.

Before my last change, I start a child process using a tokio::process::Command and listen for a Ctrl + C signal with tokio::signal::ctrl_c() with both in a tokio select! macro to make the first ready stop the other one.

In my last change, I've added the possibility to listen users keyboard events thanks to rustyline with a custom struct. This also can listen for Ctrl + C (and seems to be in priority to tokio::signal::ctrl_c()) so I removed the tokio::signal::ctrl_c() of the select.

It works fine, but the select! does not stop the child process anymore even when the CLI is closed. I've tried to set kill_on_drop to true to the Command, but it does not seem to change any thing.
Do someone have any idea ?

[hawkw]

Unlike async tasks, blocking tasks cannot be canceled once started, and will always run to completion. select! can select the output first blocking task to complete, but cannot be used to cancel blocking tasks.

[taorepoara]

It's not the blocking task that I want to cancel, but the other one that starts a Command, when the blocking task is done.
I've made some other tests and the kill_on_drop is needed to work as I expect.
Also, it seems to have a problem on Command to inherit the stdout when using output().await.unwrap() but it works fine when using .spawn().unwrap().wait_with_output().await.unwrap().

[taorepoara]

I have made some other tests and found out that the problem was only with docker compose command. I have better looked at the process list and docker compose runs a sub-process docker-compose.

The process tree look like this:

my-cli`
--> docker compose logs -f
     --> docker-compose logs -f

The select! actually works fine, the problem comes from the docker command. It does not stop the sub-process when it's killed, so the docker-compose logs -f command remains as an orphan.

[taorepoara]

One last comment to say that this problem have been solved in Docker compose: docker/compose#8880