Proposal make `suspendCancelableCoroutine` a part of the lan

Question

Proposal make `suspendCancelableCoroutine` a part of the language instead of `suspendCoroutine` as a more general and tweakable language unit

elizarov · Answer

Unfortunately adding `suspendCancellableCoroutine` would mean adding `Job` and all it cancellation machinery which contains quite a lot of code That is too much for our vision of Kotlin standard library Moreover while the contract are quite stable since `kotlinx coroutines` version `1 0` we are still evolving implementation details considerably

Alexander Vtyurin · Answer

=C Is there a way to provide minimum cancelable logic into `suspendCoroutine` keeping a way to integrate with it from `kotlinx coroutines` simple Like I have a small pet project and I don t want to pull whole coroutines with me I only want an ability to cancel it

louiscad · Answer

Why don t you want to pull whole kotlinx coroutines in that project exactly

simon.vergauwen · Answer

I ve had the same paint point

simon.vergauwen · Answer

gt Why don t you want to pull whole kotlinx coroutines in that project exactly AFAIK the reason for separation std and kotlinx was so that you didn t have to rely on kotlinx and can simple rely on std

simon.vergauwen · Answer

Is there any technical reason why `suspendCancelableContinuation` and `startCancelableContinuation` can t be separated from `Job` or other kotlinx implementation details Or could it be separated by other abstractions

gildor · Answer

But you need some abstraction some CoroutineContext for cancellation which is what Job is

gildor · Answer

I would prefer to extract suspendCancelableContinuation and Job to some kotlinx coroutines cancellation artifact which will be even more core part of kotlinx coroutines so it would be possible to use it for third party implementations without dependency on higher level primitives personally I would also prefer to separate Flow and Channels from core

gildor · Answer

Would be also interesting to have the same for dispatchers

raulraja · Answer

Would that impose cooperative cancelation over libraries Imo built in cancellation is fine but if it s abstract enough for library authors to add their own semantics

gildor · Answer

Job is just an interface so it should be possible to provide own behavior with own Job implementation it just should follow Job state contract

elizarov · Answer

Job is a use only interface It has non trivial state machine and exception handling logic to make sure they are never lost We have not yet found a way how to abstract it to make 3rd party implementations of this interface possible and safe at the same time

elizarov · Answer

Unfortunately dispatchers are also integrated with cancellation both for functionality make sure cancelled coroutines do not run normally and for some performance optimizations avoiding extra wrapper objects allocations

elizarov · Answer

Anyway simplifying Job and making it possible to be alternatively implemented is an extremely desirable thing I d love to do it just have not figured out how

gildor · Answer

I think it s fine to have separate Dispatchers artifact with cancellation in dependencies

simon.vergauwen · Answer

Those all sound like kotlinx impl details Generic cancelation is just about a handler and cancelable reference no Which is what we d care to abstract from Job

Alexander Vtyurin · Answer

Yes maybe it will make `std` weight a couple of kilos more but anyway I think that it is more correct for `suspendCancelableCoroutine` to be a part of a language because without it no one can implement their own `com username kotlin coroutines` that will be compatible with `kotlinx` at least in some way Especially in a case when `Job` impl is complex and should not be touched without knowledge

gildor · Answer

It s not a problem of a couple of kilos

gildor · Answer

What is added to stdlib once cannot be removed changed in a backward incompatible way never in Kotlin 1 x

gildor · Answer

Why add something to language if it may be extracted to library with much faster release schedule and softer backward compatibility rules

Alexander Vtyurin · Answer

gt Unfortunately adding `suspendCancellableCoroutine` would mean adding `Job` and all it cancellation machinery which contains quite a lot of code So you re saying that JB team is not sure for current `Job` impl and there are risks in this decision if sometime later you ll decide to reimplement it

gildor · Answer

Sure why not

simon.vergauwen · Answer

`suspendCancelableContinuation` should be decoupled from `Job`

gildor · Answer

Also Job is not an implementation

gildor · Answer

gt `suspendCancelableContinuation` should be decoupled from `Job` And how would it work

gildor · Answer

You need some coroutine context that keeps coroutine state let s name it for example Job

simon.vergauwen · Answer

`Job` currently leaks kotlinx details

gildor · Answer

Not sure exactly but of course it may be

gildor · Answer

so it means that we need some lower level primitive for this

gildor · Answer

which doesn t exist yet

gildor · Answer

Move suspendCancelableContinuation to stdlib is not just copy one function

gildor · Answer

Not sure why we discussing it again it s exactly what Roman said above <https kotlinlang slack com archives C0B9K7EP2 p1561619268110300 thread ts=1561577221 102900 amp cid=C0B9K7EP2>

simon.vergauwen · Answer

It should just be a plain cancelation contract However it s modeled best for Kotlin

gildor · Answer

which doesn t exist yet

gildor · Answer

I mean we are trying to discuss moving to stdlib code that not even exist

simon.vergauwen · Answer

Exactly

gildor · Answer

And before move it to stdlib it should be at least tested on kotlinx coroutines

gildor · Answer

and to do this it should be extracted to own library to test how it works with 3rd party implementations

gildor · Answer

and if it extracted what is the point to bundle it to stdlib if it not even used there

simon.vergauwen · Answer

You can write cancelable coroutine code by just using the std

simon.vergauwen · Answer

Continuation can be run in many different ways Not just kotlinx

gildor · Answer

No you cannot you cannot even run it using stdlib

simon.vergauwen · Answer

You can

simon.vergauwen · Answer

The new IO in Arrow does exactly that

gildor · Answer

But you have own dispatchers as I understand isn t it

simon.vergauwen · Answer

No

gildor · Answer

What do you use to run it

simon.vergauwen · Answer

`startCoroutine`

simon.vergauwen · Answer

With `suspendCancelableContinuation` we could integrate IOs cancelation in an interopt way

simon.vergauwen · Answer

If that was not the original goal of this proposal than I miss understood

gildor · Answer

But because suspendCancelableContinuation is not enough

gildor · Answer

we returning back to Job

simon.vergauwen · Answer

Why is `suspendCancelableContinuation` not enough

simon.vergauwen · Answer

You d also need `startCoroutineCancelable` if that s what you mean

gildor · Answer

How would it be implemented

gildor · Answer

My point that to get some result with this feature request better to discuss what is not enough for your implementation and propose to extract this part to separate library and create task on kotlinx coroutinws tracker so it would be possible to write third party implementations without waiting for stdlib

gildor · Answer

Also even now CancellableContinuation has experimental APIs

simon.vergauwen · Answer

I don t expect this to happen anytime soon as building or architecting cancelable effect systems is very difficult Probably the hardest thing I ve done till date myself was the work on Arrow s IO and specifically cancelation

simon.vergauwen · Answer

I was still more wondering if it s a good fit on a language level I do have a good use case for it but nothing that can t be solved atm by offering an kotlinx integration module

simon.vergauwen · Answer

That doesn t change the fact that it s broken IMO It should be sufficient to integrate with std but all cancelation out there currently requires the need for kotlinx I e Android there is not way to integrate cancelation on a language level All libraries need to provide custom integrations which is horrible for library authors and also for users

elizarov · Answer

Sorry but I don t see how the discussion on cancellation decoupling is relevant to stdlib I totally agree with what < gildor> said When we figure out how to decouple cancellation from the rest of `kotlinx coroutines` it would still make total sense to keep it separately I don t see much benefit in adding it to the stdlib whoever needs it can easily add a dependency

simon.vergauwen · Answer

May I ask why The power of being able to define cancelable suspending function based on the std seems exactly what you d want If it s tied to a library that seriously weakens the power of `suspend` as a language feature as a result imo

elizarov · Answer

Because there is no point in just keeping adding stuff to stdlib None It s year 2019 Dependencies were invented long time ago

elizarov · Answer

we don t want to turn into yet another Java

simon.vergauwen · Answer

Fair but not sure I understand why Kotlin shouldn t support cancelable suspending function as a language feature

simon.vergauwen · Answer

And or make the existing std operators cancelable aware

elizarov · Answer

Because it has nothing to do with a language Suspension support is a language feature Cancellation is totally library feature

simon.vergauwen · Answer

Is there any resource or technical paper on this I m not sure I understand why

simon.vergauwen · Answer

Is this something other language have discussed

elizarov · Answer

You can read the paper on design of coroutines in Kotlin <https github com Kotlin KEEP blob master proposals coroutines md>

elizarov · Answer

It describes the language design for suspension and does not mention cancellation because it is not related to cancellation in any way

elizarov · Answer

Moreover I ve never seen a language where cancellation is supported on language level For all I know it is always implemented in a library

simon.vergauwen · Answer

Thank you for the reference On a similar note what would recommend for Arrow s IO Interopt in an uncancelable manner using std tools and provide a seperate kotlinx module to integrate IOs cancelation with `CoroutineScope` structured concurrency I e for easy interopt with Kotlinx on Android

louiscad · Answer

< simon vergauwen> I d recommend to use non experimental APIs of kotlinx coroutines simply If size is a concern some people will be writing assembly others will use R8 Proguard DCE or other binary optimizers

simon.vergauwen · Answer

< louiscad> we don t rely on Kotlinx in Arrow Fx It ll be a seperate artifact to integrate with Kotlinx so all integrations that makes sense will be included Edit we don t rely on Kotlinx coroutines we rely on some others and might more in the future with libs like atomicfu and clock