Skip to content

Nested task_spawn with block_on is not working #760

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

Closed
manikawnth opened this issue May 1, 2020 · 5 comments
Closed

Nested task_spawn with block_on is not working #760

manikawnth opened this issue May 1, 2020 · 5 comments

Comments

@manikawnth
Copy link

manikawnth commented May 1, 2020

Nested block_on works:

task::block_on(async {
    task::block_on(fib_async(45));
});

Nested task_spawn with await works:

let s = task::spawn( async {
    task::spawn(fib_async(45)).await;
});
    
task::block_on(s);

but nested task_spawn with block_on doesn't work:

let s = task::spawn( async {
    let s1 = task::spawn(fib_async(45));
    task::block_on(s1);
});
    
task::block_on(s);

Version:
async-std = "1.5.0"

Not sure if I'm doing something obviously wrong!

@skade
Copy link
Collaborator

skade commented May 1, 2020

Could you please clarify what "doesn't work"? Do you observe a panic or a lock?

@manikawnth
Copy link
Author

manikawnth commented May 1, 2020

Either it's a lock or an infinite loop. The terminal hangs forever.

This is the full example

use async_std::task;

fn main() {
    let t = task::spawn(async {        
        println!("parent task spawned");
        let nested_t = task::spawn(async {
            println!("nested task spawned");
        });        
        task::block_on(nested_t); //this doesn't return
        //nested_t.await;   //this yields
    });    
    task::block_on(t);    
    println!("never reaches here incase of nested block_on");
}

@dignifiedquire
Copy link
Member

block_on inside spawn should really be detected, it doesn't make much sense asfaiu. If you want to block, you can use .await

@Licenser
Copy link
Contributor

I'm not sure "doesn't make sense" applies here. Yes in the above, simplified, for example it seems nonsensical but in most applications we don't have control over every library that is used or it is possible for some code path to be synchronous for other reasons.

So if a library uses block_on anywhere in their code it becomes unusable in asynchronous code which is a bit of a bummer.

And the same applies to block_on in a block_on too.

@dignifiedquire
Copy link
Member

Fixed in #799

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

4 participants