Hi, can't the `cancel()` methods in `Channel` and `Job` be optimized to not allocate a new `Cancella...

# coroutines

[louiscad]

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?

[Vsevolod Tolstopyatov [JB]]

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<*> 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.

[louiscad]

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

[Vsevolod Tolstopyatov [JB]]

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

[Vsevolod Tolstopyatov [JB]]

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

[louiscad]

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<*> instance plus the stacktrace filling?

[Vsevolod Tolstopyatov [JB]]

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.

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.

[louiscad]

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