https://github.com/tokio-rs/tokio/issues/2316

[avnerbarr]

similar to #2316

test code is as follows:

This runs as expected

#[test]
fn test_timers() {
    let mut rt = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .enable_time()
        .build()
        .unwrap();

    rt.block_on(async {
        println!("waiting");
        let _ = tokio::time::sleep(std::time::Duration::from_secs(3));
        println!("finished waiting");
    });
}

But with timers if they expire it will crash for me:

#[test]
fn test_timers() {
    let mut rt = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .enable_time()
        .build()
        .unwrap();

// this crashes
    let f = tokio::time::timeout(std::time::Duration::from_secs(1), async {
        println!("waiting");
        let _ = tokio::time::sleep(std::time::Duration::from_secs(3));
        println!("finished waiting");
    });
    rt.block_on(f);
}

there is no reactor running, must be called from the context of a Tokio 1.x runtime
thread 'a::test_b' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime'

Example:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7b24d2085a3127c2e7f073091c90eff7

[avnerbarr]

maybe this explains? what is the workaround?

/// It can also panic whenever a timer is created outside of a
/// Tokio runtime. That is why `rt.block_on(sleep(...))` will panic,
/// since the function is executed outside of the runtime.
/// Whereas `rt.block_on(async {sleep(...).await})` doesn't panic.
/// And this is because wrapping the function on an async makes it lazy,
/// and so gets executed inside the runtime successfully without
/// panicking.
#[track_caller]
pub fn timeout<T>(duration: Duration, future: T) -> Timeout<T>
where
    T: Future,
{

[Darksonn]

This is because your timer is created outside of the runtime. This works:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=21d7db1919bafbd3ea75cacefd3fef0a

[avnerbarr]

Yes! of course after posting this question figured it out (had to go through the stack trace and read the documentation of the internals!)

Maybe we can add a check that this is the case and have an easy to read message?

Another issue I have now (unrelated possibly) is that the test will complete but then I will get a message like:

thread 'tokio-runtime-worker' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /tokio-1.15.0/src/runtime/blocking/shutdown.rs:51:21

[avnerbarr]

(I have a spawned task in the function being tested + a timed task)
pseudo:

fn work(&self) -> Result {
    self.rt.spawn( async work in background);
    // but return some intermediate result with a timeout per the question you have answered
    self.rt.block_on(get_with_timeout per the question above...)
}

#[test]
fn test_work() {
  let x = ...;
   x.work();
}

[Darksonn]

Cannot drop a runtime in a context where blocking is not allowed.

You are dropping a runtime from inside a runtime. Did you create two runtimes?

[avnerbarr]

It might have been created deeper inside. Is there some constraint on how many runtimes to have? Should runtimes be shared across modules / crates? if so how ?

[Darksonn]

There's no constraint on the number of runtimes, but you can only use one runtime at the time on a single OS thread. It is generally more performant to share a single runtime, and most projects should not create more than one.

[Darksonn]

You should be doing this:

async fn work2() {
    // Wrap any use of the blocking Legacy object in `spawn_blocking`.
    tokio::task::spawn_blocking(|| {
        let b = LegacyBridge::new();
        b.work_with_timeout();
    }).await.unwrap();
}

[avnerbarr]

👍 anyway to have a compile time check for this? I only now understand that I can uncover these issues at runtime, and that can lead to regressions no? (untested changes could crash at runtime with errors like: "Cannot start a runtime from within a runtime. This happens \ because a function (like `block_on`) attempted to block the \ current thread while the thread is being used to drive \ asynchronous tasks."

)

[Darksonn]

Unfortunately there's no compile-time check for this. There are several ideas for how to add something like that to the language, but none of them are implemented.

[avnerbarr]

How would you go about running async code in parallel with sync code from legacy sync code?
for example:

// sync function
fn do_work_in_parallel(&self) -> Vec<String> {
   // want to run do_work and do_work_async in parallel, combining the results 
// should I create a runtime each time the method is called (or perhaps an instance runtime? I have many of these objects possibly) vs should I use tokio::task::spawn_blocking (or some variation?) ... etc. etc.
   // what I want is w1 and w2 in parallel and then to wait and combine the results
   let w1 = do_work();  
   let w2 = do_work_async(); 
  return  w1 + w2
}

// the legacy sync work
fn do_work(&self) -> Vec<String>{
}

async fn do_work_async(&self) -> Vec<String>{
}

[Darksonn]

You can do that like this:

fn do_work_in_parallel(&self) -> Vec<String> {
    let w1_handle = spawn_blocking(|| do_work());
    let w2 = do_work_async().await;
    let w1 = w1_handle.await.unwrap();
    return w1 + w2;
}