Panic occurs when using tokio::task::spawn in Drop when running in a LocalSet

[acheronfail]

I've got a repository demonstrating the problem if you want a very simple reproduction case: https://github.com/acheronfail/tokio-local

The Problem

I'm running an application which is trying to be completely single-threaded. It does this by using tokio's current_thread runtime, and then running everything within a LocalSet (to allow for !Send types).

I've noticed that one of the libraries I depend on uses tokio::task::spawn in one of its struct's Drop implementation - this spawn causes my runtime to panic with there is no reactor running, must be called from the context of a Tokio 1.x runtime.

I think this representation might help understand the issue:

task started with	spawn used in Drop	panic	expected
tokio::task::spawn	tokio::task::spawn	No	Yes ✅
tokio::task::spawn	tokio::task::spawn_local	Yes: if not running within LocalSet	Yes ✅
tokio::task::spawn_local	tokio::task::spawn	Yes: no reactor running	No ❌
tokio::task::spawn_local	tokio::task::spawn_local	No	Yes ✅

---

I'm not sure how to solve this, since I don't control the code inside the Drop implementation (it's in a library) so I can't just change it to spawn_local to workaround my issue.

What I find confusing is that the panic is that there's no reactor running, but there is one running, it's just in a LocalSet.

Have I missed something obvious? Or is this an issue with tokio?

[acheronfail]

So, the unexpected panic occurs when starting the runtime like so:

let runtime = Builder::new_current_thread().enable_all().build().unwrap();
LocalSet::new().block_on(async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn));
// thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', src/main.rs:88:34

However, I've noticed some interesting behaviour which may be a hint. Wrapping the LocalSet within runtime.block_on:

// runtime.block_on
let runtime = Builder::new_current_thread().enable_all().build().unwrap();
runtime.block_on(LocalSet::new().run_until(async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn)));
// thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', src/main.rs:88:34

Still panics. However, this - which was unexpected to me - stops the panic from occurring:

// runtime.block_on with wrapped LocalSet
let runtime = Builder::new_current_thread().enable_all().build().unwrap();
runtime.block_on(async {
    LocalSet::new()
        .run_until(async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn))
        .await;
});
// no panic 🎉

---

So, this is at least a workaround.

[Darksonn]

You get a panic if you call tokio::spawn while not inside a runtime, so if you drop the LocalSet from outside a runtime, then you get the panic.

The run_until solution works because it drops the LocalSet inside the runtime (because it's inside a call to block_on).

[acheronfail]

The run_until solution works because it drops the LocalSet inside the runtime (because it's inside a call to block_on).

I would have expected that these two run the same, since they're both inside a call to block_on:

// A
runtime.block_on(LocalSet::new().run_until(async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn)));
// B
runtime.block_on(async {
    LocalSet::new()
        .run_until(async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn))
        .await;
});

The way I see it - in both of these cases - the LocalSet is dropped from within an async context - one is just wrapped in an additional async {} block.

However, it seems that this isn't the case? I think this may be due to where exactly the LocalSet is dropped.

Is this the correct understanding?

let fut = async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn);

// A
runtime.block_on(
    // <-- LocalSet created here
    LocalSet::new().run_until(fut)
    // <-- Runtime::block_on runs LocalSet, and once it's finished, its async context is closed
    // <-- LocalSet dropped here, after the Runtime's async context has closed
    // <-- panic occurs because LocalSet attempts to spawn a task on Drop
);
// B
runtime.block_on(
    // <-- async block created here
    async {
        // <-- LocalSet created here
        LocalSet::new().run_until(fut).await;
        // <-- LocalSet completed here after .await
    } // <-- LocalSet dropped at the end of this async block - still within Runtime::block_on's async context
    // <-- Runtime::block_on's async context is finally closed here, nothing else is dropped
);

[acheronfail]

You get a panic if you call tokio::spawn while not inside a runtime, so if you drop the LocalSet from outside a runtime, then you get the panic.

Also, as noted in my original question, you'll see it's a little more subtle than this. The panic only occurs when calling tokio::task::spawn in the Drop implementation - calling tokio::task::spawn_local does not panic! Hence my confusion.

If you refer to the table you'll see that it's only the combination of starting a task with spawn_local and using spawn in a Drop impl that causes the panic. It may very well be because of where the Drops occur as I described in my reply just above, but the fact that it only happens with this combination of spawn_local + spawn I find very unexpected.

If it were just that a panic occurs while not inside a runtime - I would have expected that all entries in the table would have caused the same panic.

[Darksonn]

A is equivalent to this:

let local_set = LocalSet::new();
let future = async_main(SpawnMethod::SpawnLocal, DropMethod::Spawn);
runtime.block_on(local_set.run_until(future));
drop(local_set);