I have this situation: I run a process through tokio_processspawn_async, and I want to use a tokio::timer::Timeout to stop the process after a certain amount of time if not closed.
However, for reasons, I need to avoid a kill and I need to do IPC to send a "perform a shutdown" signal and wait for the child to complete. The problem is that Timeout resolves in the error when the timeout occurs, leaving me without the tokio_process::Child future and the possibility of waiting for its termination (or forgetting it).
Do you have any hints on how this situation should be handled?
I can use IPC to wait for the cleaning procedure in the child to be completed, in order to avoid problems if I kill the process. But it is a dirty workaround, and I would like to avoid it.
EDIT: ok, how to avoid putting the emoji in the title instead of :timer:?
Hmm, you may want to file an issue in the tokio timer crate asking to return the underlying value in the timer elapsed case.
As an alternative, try using Delay and select() it against the tokio_process future - select will give you the process future if the Delay completes first.
I want to ask you your opinion about my purpose: is it a good situation, or I am trying to use Timeout in a way it is not supposed to work? I am doubtful because one could expect the future that timed out to be resolved. I don't know if the behaviour I am searching for could raise other different problems that we would like to avoid.
That's exactly what I was trying to do now. However, I have another kind of problem: I was already using select2 (I think I can use select, with the last version of tokio they should be the same, aren't they?), so now I need to use two nested Select2/Select, or select_all and some kind of array of dyn Trait, where the trait is some custom one that can handle different types of Future::Item... Or maybe it is better to write down a custom Select3Ext?
I am really open to different approaches, and feel free to suggest me if it could be worth to open an issue on the tokio timer crate.
In general, it seems reasonable to return the inner future when a Timeout expires. The answer to your scenario may be “use Delay instead”, but I think this warrants a discussion in the repo.
When using combinators gets a bit unwieldy, I personally tend to write a custom Future impl that’s specific to my case - the resulting code looks cleaner to me.
