which causes a panic if you do something like:

use agnostik::prelude::*;
use tokio::runtime::Runtime;

fn main() {
    // see tokio docs for more methods to create a runtime
    let runtime = Runtime::new().expect("Failed to create a runtime"); // 1
    let runtime = Agnostik::tokio_with_runtime(runtime); // 2

    let result = runtime.spawn(async { 1337 });
    let result = runtime.block_on(result);

    assert_eq!(result, 1337);
}

(this is the code example from the agnostik docs)

My "fix" for this problem requires that the runtime is wrapped in an Arc that is cloned on each spawn, to prevent deadlocking on spawn calls inside of block_on. This isn't that ideal...

Also there is no way to use the current runtime in TokioExecutor::spawn_local.

Stopping exposing all the spawn fns, but block_on on the Executor could be better?

Or even removing the AgnostikExecutor & LocalAgnostikExecutor traits all together and just exposing a minimal set of apis through the "global" spawn etc fns? The excutor traits are just wrappers over the runtimes "global" spawn fns anyway. If there is a need for someone to start a custom runtime, then they could just use the block_on fn on tokios runtime directly (and there is no support in agnostik to change the runtime of the other async executors). This would prevent users from implementing their own custom executors and passing those a generic argument through their application (or an extension in agnostik to support custom executors in global spawn fns), see #4

What do you think?