You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
use agnostik::prelude::*;use tokio::runtime::Runtime;fnmain(){// see tokio docs for more methods to create a runtimelet runtime = Runtime::new().expect("Failed to create a runtime");// 1let runtime = Agnostik::tokio_with_runtime(runtime);// 2let 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?
The text was updated successfully, but these errors were encountered:
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.
agnostik/src/executor/tokio.rs
Line 34 in 16184b4
which causes a panic if you do something like:
(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 eachspawn
, to prevent deadlocking onspawn
calls inside ofblock_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, butblock_on
on theExecutor
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 theblock_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 #4What do you think?
The text was updated successfully, but these errors were encountered: