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

.await inside .spawn() stuck indefinitely #14

Open
Systemcluster opened this issue Apr 7, 2021 · 1 comment
Open

.await inside .spawn() stuck indefinitely #14

Systemcluster opened this issue Apr 7, 2021 · 1 comment
Labels
bug Something isn't working wontfix This will not be worked on

Comments

@Systemcluster
Copy link

Systemcluster commented Apr 7, 2021

While testing some async code shuffling handles between threads I came across a case where .await inside .spawn() doesn't return.

I created a repro case here: https://github.com/Systemcluster/switchyard/blob/trunk/tests/repro.rs

Running with cargo test -- --nocapture makes it apparent that one of the futures gets stuck here: https://github.com/Systemcluster/switchyard/blob/trunk/tests/repro.rs#L25


While simplifying the repro case I narrowed it down a bit: If the inner load function doesn't get passed an Arc containing the Switchyard, it doesn't get stuck.

Changing these two lines

async fn load(_name: String, _yard: Arc<Switchyard<()>>) -> Self {
//...
let resource = ResourceA::load(name.clone(), _yard);

to

async fn load(_name: String) -> Self {
// ...
let resource = ResourceA::load(name.clone());

makes it work as expected without getting stuck.

@cwfitzgerald cwfitzgerald added wontfix This will not be worked on bug Something isn't working labels Apr 7, 2021
@cwfitzgerald
Copy link
Member

Repeating what we discussed on discord:

https://github.com/Systemcluster/switchyard/blob/trunk/tests/repro.rs#L14 dropping yard here is the last reference to switchyard, which drops switchyard, which waits on all threads to be finished. This causes the switchyard worker thread to wait for itself to finish.

So this seems to be a user bug, but should we detect this situation and not block on drop?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants