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

async-std@1.6.0-beta.1: cannot run an executor inside another executor #766

Closed
GopherJ opened this issue May 8, 2020 · 6 comments
Closed

Comments

@GopherJ
Copy link

GopherJ commented May 8, 2020

after upgrading to 1.6.0-beta.1, I start to get this error message. Previous version: 1.5.0

@dignifiedquire
Copy link
Member

This sounds like you are running block_on inside another block_on, which was not really well supported before, but is now being detected and not ignored anymore.

@GopherJ
Copy link
Author

GopherJ commented May 8, 2020

@dignifiedquire I removed block_on inside block_on but all my tests still fail, the compiler doesn't complain about the changes but I'm failling tests, would you mind having a look? I would like to test the new version of async-std for https://github.com/casbin/casbin-rs because maybe wasm compiles so that we can finally resolve: casbin/casbin-rs#101

https://github.com/GopherJ/casbin-rs/tree/upgrade-async-std

@GopherJ
Copy link
Author

GopherJ commented May 8, 2020

Also this error is a runtime error which makes it harder to identify during compile time, is it possible to locate it during compile time?

cargo check always ok but when we run/test it, errors come

@andysalerno
Copy link

andysalerno commented May 9, 2020

I'm receiving the same error. At first it was throwing from a block_on, so I removed the block_on and have none remaining in (my) codebase, then it began throwing from another line.

From inspecting the trace, it looks like there's a block_on in async-std-1.6.0-beta.1/src/fs/file.rs:318.

In my code, the File is going out of scope, I guess invoking the drop() of the File, which leads to a stack trace like this, which I guess involves a block-in-a-block (since my main() is decorated with the async_std::main attribute):

  21: async_std::task::block_on::block_on
             at /home/andy/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.6.0-beta.1/src/task/block_on.rs:33
  22: <async_std::fs::file::File as core::ops::drop::Drop>::drop
             at /home/andy/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.6.0-beta.1/src/fs/file.rs:318
  23: core::ptr::drop_in_place
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ptr/mod.rs:177
  24: core::ptr::drop_in_place
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ptr/mod.rs:177
  25: toygrep::buffer::async_line_buffer::AsyncLineBufferReader<R>::take_line_buffer

https://github.com/async-rs/async-std/blob/master/src/fs/file.rs#L318

Agree with @GopherJ -- if blocking inside a blocking scope is now illegal, then hopefully there is some static way to detect this, since any instance of a block_on anywhere in your dependencies will start throwing at runtime (even within the async-std libraries itself, apparently).

@andysalerno
Copy link

andysalerno commented May 9, 2020

(this comment previously had an old investigation with some incorrect info, now I have updated it to be accurate)

I just tested, and this is indeed failing:

fn main() {
    async_std::task::block_on(async move {
        async_std::fs::File::open(".").await.unwrap();
    });
}

thread 'main' panicked at 'cannot run an executor inside another executor', <::std::macros::panic macros>:2:4

@dignifiedquire
Copy link
Member

Thank you @andysalerno for the test and report. #768 fixes the case for File dropping.

@GopherJ GopherJ closed this as completed May 9, 2020
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