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
Pretty much all composite futures in Chronos do not propagate cancellations. For example, here is what the documentation is saying about allFutures:
## Returns a future which will complete only when all futures in ``futs``
## will be completed, failed or canceled.
##
## If the argument is empty, the returned future COMPLETES immediately.
##
## On cancel all the awaited futures ``futs`` WILL NOT BE cancelled.
The treatment is similar for and, or, all, race.
What's the rationale behind this design choice? My expectation is that composite futures should propagate cancellation. For example, imagine I have the following async proc:
Naturally, I expect cancelling workflowFut to immediately stop any remaining work of "job1" and "job2" that may take another several hours to complete. Instead, Chronos will let them run to completion unless I explicitly write cancellation propagation code in my startMultiHourWorkflow proc, which strikes me as the wrong default (not wanting the cancellation to be propagated should be a rare and unusual use case).
The text was updated successfully, but these errors were encountered:
Pretty much all composite futures in Chronos do not propagate cancellations. For example, here is what the documentation is saying about
allFutures
:The treatment is similar for
and
,or
,all
,race
.What's the rationale behind this design choice? My expectation is that composite futures should propagate cancellation. For example, imagine I have the following async proc:
In my application, I'm likely to have the following code:
Naturally, I expect cancelling
workflowFut
to immediately stop any remaining work of "job1" and "job2" that may take another several hours to complete. Instead, Chronos will let them run to completion unless I explicitly write cancellation propagation code in mystartMultiHourWorkflow
proc, which strikes me as the wrong default (not wanting the cancellation to be propagated should be a rare and unusual use case).The text was updated successfully, but these errors were encountered: