opened
oleg-py
username_0
Another pick from #192. We might want to have `cancelBoundary` on `Concurrent` instead of only having it on data types.

Pros:
* Tagless-style programs can express cancelable loops without relying on concrete `Concurrent` type.
* Can be naturally used with transformers too.
* IO and Task already have version that is suited to their run-loop implementation, and Scalaz 8 due to cancelable binds can return a `pure(())`
* There can be a default implementation (had it mentioned by @username_1, but I lost it 😞 ).

Cons:
* Having it sort-of implies that you need it to make loops cancelable, whereas they might be even without using it.
* Not sure if reasonable laws exist for it.
Proposal: add `cancelBoundary` as a method on Concurrent
issue
created
alexandru
username_1
I added it on Monix Task eventually in one recent commit, because as I explained, due to batching and optimizations the runtime doesn’t necessarily check for cancellation on each flatMap iteration, so it might be cool in certain instances to force it, like before some fat task doing blocking I/O. 

Same as with “shift”, even if Monix does batched processing and automatic forking, you still want to ensure in some cases that forking happens right before some task.
comment
created
alexandru
username_1
The one thing that I worry about however is that Concurrent is a fat type class. We’ll have to split it up at some point, but after 1.0.
comment
created
Daenyth
username_2
FWIW I have a use case for this in code that is otherwise only `Sync`-dependent. I've solved it so far via adding a `cancelBoundary: Option[F[Unit]]` parameter to my function arguments with guidance in the scaladoc that the user should pass `Some(IO.cancelBoundary)` if their `F` is `IO`. Inside the body I use `cancelBoundary.getOrElse(F.unit) *> stuff`
comment
created
alexandru
username_1
Btw at this point `cancelBoundary` is nothing more than `F.async(_(Right(())))`.
comment
created
alexandru
username_1
Can we close this?
comment
created
oleg-py
username_0
Yup
comment
closed
oleg-py
username_0
issue