Test for shutdown of runtime in Handle::spawn

[b-naber]

Tries to fix #3548

We use the shutdown flag of the blocking spawner's Shared field to allow a Handle to infer that the runtime was shutdown. If the flag is set, Handle::spawn and Handle::spawn_blocking will return a newly introduced JoinError::DroppedRuntime.

A potential downside is that JoinError was previously solely related to errors caused by a task itself. I couldn't find a cleaner alternative than to introduce a new kind of JoinError since returning a Result from the spawn methods breaks all kinds of things in the API.

Also I'm not 100% sure that the shutdown of the blocking spawner is always caused by the runtime being dropped.

[Darksonn]

We usually use the existing cancelled variant of the join error when the runtime shuts down.

[b-naber]

@Darksonn thanks, I'll change that.

[Darksonn]

What if the runtime is shut down right after the self.is_shutdown() call?

[b-naber]

Good catch. We should probably test for the shutdown after the self.spawner.spawn call.

[carllerche]

Adding a check in spawn like that is going to be vulnerable to races. Instead, the "shutdown" check needs to happen atomically when pushing into the queue.

It looks like the multi-threaded scheduler already does the right thing: https://github.com/tokio-rs/tokio/blob/master/tokio/src/runtime/queue.rs#L511-L517

For the current-thread scheduler, my guess is similar logic should go here: https://github.com/tokio-rs/tokio/blob/master/tokio/src/runtime/basic_scheduler.rs#L448

[b-naber]

@carllerche The multi-thread scheduler also hangs in this example.

Afaict this hangs because the poll method of JoinHandle sets a join waker in can_read_output, but remains pending, presumably because the runtime was dropped and was responsible for the waking.

I don't understand why the approach using the shutdown flag is vulnerable to race conditions. If you don't mind can you maybe give an example of how a race can occur here? Also why couldn't we solve this by making the shutdown flag atomic?

[Darksonn]

The issue was fixed by #3752.