https://kotlinlang.org logo
#coroutines
Title
# coroutines
l

louiscad

05/04/2018, 2:00 PM
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?
v

Vsevolod Tolstopyatov [JB]

05/04/2018, 2:45 PM
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.
l

louiscad

05/05/2018, 1:58 PM
Hi, I care about both which could be avoided by checking if it's already closed first. It would make
consume { … }
more efficient
v

Vsevolod Tolstopyatov [JB]

05/06/2018, 7:51 PM
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
l

louiscad

05/07/2018, 7:01 AM
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?
v

Vsevolod Tolstopyatov [JB]

05/07/2018, 8:13 AM
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.
l

louiscad

05/08/2018, 8:01 AM
If there is no significant slowdown, might be worth optimizing
Job.cancel
too, then
3 Views