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
…; 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?
The text was updated successfully, but these errors were encountered:
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?
The documentation for
join
reads: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 ofjoin
(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?
The text was updated successfully, but these errors were encountered: