Qi

Hi @chinedufn, sorry for the late reply. Do you still want to work on this PR? If so, could you resolve the merge conflicts? If not, may I take over...

Did you try `strace -p ` while killing the non-zombie child process?

> use this crate 'signal-hook-tokio' , may be this crate's problem ? [link](https://github.com/vorner/signal-hook) @jokemanfire It is possible, without a minimal reproducible example, it is hard for us to move forward...

This might be similar to https://github.com/rust-lang/rust/issues/67939.

You may want [`tokio::io::BufReader`] plus [`tokio::io::AsyncBufReadExt:lines`]. [`tokio::io::BufReader`]: https://docs.rs/tokio/1.48.0/tokio/io/struct.BufReader.html [`tokio::io::AsyncBufReadExt:lines`]: https://docs.rs/tokio/latest/tokio/io/trait.AsyncBufReadExt.html#method.lines

I closed this issue as there is a solution. Feel free to reopen this issue if you have any follow up comments.

> We will need to consider the changes to behavior. What if creation and first poll happen on two different runtimes? Maybe the change is acceptable, but we should be...

> I think the most significant change is whether creating a `Sleep` outside of a runtime panics or not. Right now it panics, but if we delay registration I imagine...

> It looks like there is a test for it: > > https://github.com/tokio-rs/tokio/blob/911ab21d7012a50e53971ad1292a9f18de22d4c8/tokio/tests/time_sleep.rs#L173-L181 > > If that still passes with your change, I guess it already panics when created outside...

Hi @Darksonn , do you have other concerns about the behavior changes introduced by this PR? I'm not rushing anything, behavior changes are always tricky for projects like tokio, it...