"No reactor running" in async task run within a dylib loaded by FFI/libloading

[alshdavid]

I'm writing an application that dynamically consumes a library that has some extern functions exported via Rust's FFI

/target
  /debug
    main
    lib.so

// /dynlib/lib.rs

pub extern fn init() -> Box<Pin<Box<dyn Future<Output = usize>>> {
  Box::new(Box::pin(async move {
    tokio::tak::spawn(async {
      42 as usize
    }).await.unwarp()
  })
}

Using libloading I load the lib.so file, obtain the init function, run it and await the future it returns.

// /consumer/main.rs
async fn main_async() {
  let lib = unsafe {
    libloading::Library::new(lib_path).unwrap()
  };

  let init_fn: libloading::Symbol<unsafe fn() -> Box<Pin<Box<dyn Future<Output = usize>>>> = unsafe {
    lib.get(b"init").unwrap()
  };

  println!("{}", init_fn().await);
}

fn main() {
  tokio::runtime::Builder::new_multi_thread()
    .enable_all()
    .build()
    .unwrap()
    .block_on(main_async());
}

The tokio runtime is executed in the main application and I assumed the context would be shared with dynamically loaded library however, at the tokio::spawn, I get the error:

there is no reactor running, must be called from the context of a Tokio 1.x runtime

I assume that means the solution would be to spawn a new tokio runtime within the dynamic library, this seems to work.

// /dynlib/lib.rs

async fn init_async() -> usize {
  tokio::tak::spawn(async {
    42 as usize
  }).await.unwarp()
}

pub extern fn init() -> Box<Pin<Box<dyn Future<Output = usize>>> {
  Box::new(Box::pin(async move {
    tokio::runtime::Builder::new_multi_thread()
      .enable_all()
      .build()
      .unwrap()
      .block_on(init_async())
  })
}

I was hoping I could reuse the tokio runtime from the host process, is that possible?

Otherwise, what sort of performance implications are there for having a second tokio engine running in the dynamic library?

[alshdavid]

What's interesting is that the solution I proposed doesn't work with traits where methods are invoked via dynamic dispatch.

• Working with an "add" function
• Working with an "Adder" struct
• Breaking with an "Adder" trait + dynamic dispatch

[alshdavid]

Ah, looks like returning the future from the block_on is what causes it to detach from the runtime.

If I return a struct then it uses the parent Tokio runtime but that doesn't work when returning a trait.

[Darksonn]

Each dylib will end up with a separate copy of Tokio, and they will not work together. For example, tokio::spawn works by accessing a global variable, but if you have two copies of it and access the wrong copy, then spawning will not work.

Having multiple copies of Tokio is an unsupported configuration.

[alshdavid]

I see. Why does it work when I import a struct from the dylib rather than a trait?

[Darksonn]

The problem isn't the dynamic dispatch but the fact that you call tokio::spawn. Your second example doesn't do that.

[alshdavid]

Ah sorry, I didn't commit it (I'll add it shortly) - with the tokio::spawn in the add() method whist returning an AddMachine struct - the call to add(1,2).await works from the consumer crate.

I realized that it uses the consumer's Tokio context so I don't need to spawn a nested runtime in the dynamic library.

However if the dynamic lib returns a Box<dyn Adder> the Tokio runtime fails telling me that it needs to run within a reactor.

In that case, I could spawn a new (nested?)Tokio::Runtime, add it to the AddMachine struct and use rt::spawn in the internal methods - but I cannot drop the nested runtime because that's not supported.