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
make_ready_future uses the default executor implicitly, which doesn't matter for the future itself, but does for continuations that don't explicitly specify the executor. It seems like providing an executor argument to make_ready_future would make the API more consistent.
Currently, if you have one or more custom executors, you have to be always sure to pass them when calling .then if you use make_ready_future somewhere (and can't consistently have the continuation use the same executor as the previous).
The text was updated successfully, but these errors were encountered:
Thanks. #65 suggests my understanding is correct, but doesn't address the problem I see (with having to be careful to avoid having the default executor sneak in unexpectedly from make_ready_future).
make_ready_future
uses the default executor implicitly, which doesn't matter for the future itself, but does for continuations that don't explicitly specify the executor. It seems like providing an executor argument to make_ready_future would make the API more consistent.Currently, if you have one or more custom executors, you have to be always sure to pass them when calling
.then
if you usemake_ready_future
somewhere (and can't consistently have the continuation use the same executor as the previous).The text was updated successfully, but these errors were encountered: