Synchronous nature of join might result in suboptimal use of compute resources

[zopsicle]

The documentation for join reads:

…; if however closure B has been stolen, then it will look for other work while waiting for the thief to fully execute closure B.

Even if closure B completes before the “other work” completes, the code following the call to join cannot run immediately after closure A and closure B complete, even if there is a free thread on the thread pool. It must wait for the “other work” to complete, which might take a long time compared to closures A and B, with no way to prefer certain tasks to be considered “other work” candidates (AFAIK).

This is only really an issue because join must return on the calling thread, by its synchronous nature. Having an async version of join (i.e. one that returns a future) would improve on this by allowing it to return on a different thread than the one it was called on, because the code before and after the await are separate tasks. It would require running futures on the thread pool.

Is this something that has been explored before?

[Josh Stone]

Asynchronous code is quite different from the user perspective, compared to Fn traits. It's not something we can just graft in automatically, but there have been experiments with futures if you search through issues. Alternatively, if you're concerned about such latency, have you considered using tokio's thread pool?