how do I cancel the children a coroutinescope and ...
# coroutines
k
how do I cancel the children a coroutinescope and not the scope itself?
d
Put the children in another scope and cancel that
o
or use
SupervisorJob()
k
I'm not sure that would work, but I can try.
If parent job is specified, then this supervisor job becomes a child job of its parent and is cancelled when its parent fails or is cancelled. All this supervisor’s children are cancelled in this case, too. The invocation of cancel with exception (other than CancellationException) on this supervisor job also cancels parent.
I will report back
o
to be clear,
SupervisorJob()
is for the scope you don't want cancelled
k
yup, Ive implemented coroutine scope where it needs to. Testing now.
Seems to still cancel the whole scope
I've done it like this
Copy code
CoroutineScope by CoroutineScope(Dispatchers.Main.immediate + SupervisorJob())
implementing CoroutineScope
o
are you calling
cancel()
on the scope itself?
k
When I need to cancel callback flows in this scope, I'm doing
this.cancel
which is the problem. It's cancelling the scope itself
And then I cannot recreate the flow later on when I need it because it cannot be collected in this scope
o
it sounds like you should be creating another child scope that you cancel, rather than re-using this scope
k
If I do that, then I would have to recreate the child scope every time I need to activate and deactivate the flow
(there are like 10 different flows bound to view events)
o
if you must do it this way, you could always do
this.coroutineContext[Job]!!.children.forEach { it.cancel() }
1
k
it seems to me that
CoroutineScope.cancelChildren
should be a thing
yeah, I'm going to do that
also might open an issue on Github
That worked. Thanks dude
d
Pretty sure
cancelChildren
is indeed a thing.
k
That is on job and not CoroutineScope
so I guess we could simplify the above code to:
this.coroutineContext[Job]!!.cancelChildren()
but, still. Wondering why it isn't on CoroutineScope itself
d
this.coroutineContext.cancelChildren()
should also be possible iirc.
☝️ 1
k
gotcha
Does that not still seem weird to you?
It seems non-intuitive to me.
d
Not particularly.
CoroutineScope
!=
Job
. The separation of
CoroutineScope
,
CoroutineContext
and
Job
is a bit.... weird though, but I'm not sure if I could do better myself.
k
The documentation of coroutinescope directly references the world
children
.
CoroutineScope should be implemented (or used as a field) on entities with a well-defined lifecycle that are responsible for launching children coroutines. Example of such entity on Android is Activity. Usage of this interface may look like this:
To me, that is justification enough itself to include a cancelChildren on this considering the other mechanisms that have children have this functionality.
a
tbh creating a new child job to put the flows into and then cancelling that sounds more right here to me
k
Do you mean coroutineScope?
a
yes, coroutineScope is just creating a Job with the outer scope’s job as parent
k
yes.
CoroutineScope.cancelChildren
would in effect be syntactic sugar for that. It feels cumbersome to be to necessitate making a singular ephemeral CoroutineScope for this kind of thing.
a
shrug it seems to be in line with how we have app/session/request “scopes” in other contexts — you’re running some flows to produce something, you put them in a Job so that all complete/get cancelled together
👍 1
g
Not every scope has Job, GlobalScope doesn't. It's also true for context, but at least context is more local than Scope