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
because using my_desync.future(…).await makes sure that the Desync stays alive until the passed closure is dropped (either because it was run or because it was canceled).
This would allow using local variables inside the closure passed to the future without capturing them.
Now, I've looked into the desync code and I can see how that's hard to implement, but I created this issue to point out that this would be nice to have in the future (no pun intended).
The text was updated successfully, but these errors were encountered:
Hi, it's been a while but I've finally found some time to implement this. The latest revision on the 0.7.0 branch splits future into future_sync and future_desync. future_sync() has the following declaration:
Note the difference here is the lifetime 'b which is how long the data in the Desync is borrowed for. ('b is within 'a and is shorter but Rust can't express this at the moment). This is a slightly annoying limitation: the data is only available while the returned future is running as other tasks on the same queue might be using it in the meantime.
Another difference from the original is that if the returned future is dropped, its execution will be cancelled.
future_desync() is the original implementation. It differs from future_sync() in that its future will complete even if the return value is dropped (so it can be used in situations where an executor is not available), and a 'desync' future can run in the background even if the thread that's awaiting it is blocked.
Hi,
Right now the signature for the future is
However, it should be possible to have this instead:
because using
my_desync.future(…).await
makes sure that the Desync stays alive until the passed closure is dropped (either because it was run or because it was canceled).This would allow using local variables inside the closure passed to the future without capturing them.
Now, I've looked into the desync code and I can see how that's hard to implement, but I created this issue to point out that this would be nice to have in the future (no pun intended).
The text was updated successfully, but these errors were encountered: