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
The Task run-loop needs to be customizable with a Task.Options case class that gets instantiated on runAsync to a Task.defaultOptions and then passed along in task implementations.
Task then can provide a helper such as executeWithOptions(f: Options => Options), such that we can then do:
The problem we are trying to solve is that there are certain instances in which Task.flatMap loops are better off not being automatically cancelable. Such a use-case has been discovered in the monix-kafka project, where we could get rid of synchronize on cancelation if flatMap-loops wouldn't automatically cancel.
Of course, in that case it is debatable whether getting rid of synchronization buys us anything. But it's certainly a valid use-case showing how in certain cases we are forced to synchronize and trigger an immediate cancelation precisely because later we might not get the chance.
Having Task.flatMap loops be auto-cancelable by default is also error-prone. It would be better if Task.flatMap wouldn't be auto-cancelable by default, with an option to turn this behavior on where needed.
The text was updated successfully, but these errors were encountered:
alexandru
changed the title
Add ExecutionModel#autoCancelableLoops property (Maybe)
Add Task.Options with an autoCancelableRunLoops property
Oct 23, 2016
The
Task
run-loop needs to be customizable with aTask.Options
case class that gets instantiated onrunAsync
to aTask.defaultOptions
and then passed along in task implementations.Task
then can provide a helper such asexecuteWithOptions(f: Options => Options)
, such that we can then do:The problem we are trying to solve is that there are certain instances in which
Task.flatMap
loops are better off not being automatically cancelable. Such a use-case has been discovered in themonix-kafka
project, where we could get rid ofsynchronize
on cancelation if flatMap-loops wouldn't automatically cancel.Of course, in that case it is debatable whether getting rid of synchronization buys us anything. But it's certainly a valid use-case showing how in certain cases we are forced to
synchronize
and trigger an immediate cancelation precisely because later we might not get the chance.Having
Task.flatMap
loops be auto-cancelable by default is also error-prone. It would be better ifTask.flatMap
wouldn't be auto-cancelable by default, with an option to turn this behavior on where needed.The text was updated successfully, but these errors were encountered: