Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TokioExecutor::spawn isn't using the set tokio runtime #34

Open
chpio opened this issue Apr 3, 2021 · 2 comments
Open

TokioExecutor::spawn isn't using the set tokio runtime #34

chpio opened this issue Apr 3, 2021 · 2 comments

Comments

@chpio
Copy link
Contributor

chpio commented Apr 3, 2021

let handle = tokio::task::spawn(future);

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?

@Stupremee
Copy link
Member

The current status of the crate is really bad and is totally buggy. We never started really using it which is why it became quite inactive and so buggy, sorry 😅

Related to your suggestion to remove AgnostikExecutor & LocalAgnostikExecutor, this crate will be totally rewritten soon supported by the wg-async-foundation with a, yet to be discussed, design and API. Once the rewrite is done, agnostik will also include abstractions for sockets, files, and stuff like that you normally get from tokio or async-std.

I will probably publish a rewritten version of this crate in the next few weeks, independent from wg-async-foundation, just to have something that works.

So this bug will probably not be fixed in the current version of agnostik.

@imkow
Copy link

imkow commented Jan 14, 2024

now it's the time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants