A modern programming language that makes developers happier.

kotlinlang

Hi, can't the `cancel()` methods in `Channel` and `Job` be optimized to not allocate a new `CancellationException` when the channel is already closed or the job is already cancelled or completed?

Hi, 
Do you care about allocation rate or stacktrace filling cost?

At the first glance channel doesn’t allocate exception when it is already closed (but it allocates `Closed&lt;*&gt;` instance which can be avoided).

Job may allocate exception sometimes after being closed (depends on cancellation mode of implementation), in `development` branch such exceptions are stacktraceless.

Hi, I care about both which could be avoided by checking if it's already closed first. It would make `consume { … }` more efficient

It makes sense for channel and `consume` pattern, but maybe it doesn’t for `Job`: each such check slows down first call to `cancel`, but speeds up next ones. And jobs are frequently cancelled once, but rarely are cancelled multiple times

in general they both can be optimized, I will take a look

Since channels will soon expose a `Job`, I guess calling `cancel()` on the channel will cancel the associated `Job`, so both `cancel()` implementations need to be optimized if the goal is to optimize for `consume`, right?
BTW, would checking for `isCompleted` really slow down the first call to `cancel` in a significant way, especially when measured against the cost of the allocation of the `Closed&lt;*&gt;` instance plus the stacktrace filling?

&gt;so both `cancel()` implementations need to be optimized, right?

Depends on the way `Job` will be integrated into `Channel`. Probably optimizing a channel is enough.

&gt;would checking for `isCompleted` really slow down the first call to `cancel` in a significant way

I doubt it, but it worth checking as part of the optimization.

If there is no significant slowdown, might be worth optimizing `Job.cancel` too, then