So this definitely looks wrong and raises the Inappropriate

Question

So this definitely looks wrong and raises the Inappropriate blocking method call warning but it works Is this actually dangerous ``` lifecycleScope launch repeatOnLifecycle Lifecycle State STARTED try session load awaitCancellation finally runBlocking This is a suspending function that performs I O and needs to complete session recordBackgroundTime ```

tad · Answer

The goal here is to write a value to disk when the lifecycle exits the STARTED state

uli · Answer

You are blocking the coroutine Is that what you want What exactly is it that should wait for the io

tad · Answer

If I don t block it the surrounding `lifecycleScope` is canceled and the I O coroutine inside `session recordBackgroundTime` does not run

tad · Answer

Would GlobalScope launch make sense here

uli · Answer

Then don t put it on lifecycle scope

tad · Answer

Sure I was just hoping to avoid a `lateinit var` or nullable property by using `awaitCancellation ` in the lifecycle scope

Nick Allen · Answer

uli · Answer

Just launch on a new scope which does not get cancelled

tad · Answer

< Nick Allen> Thanks

uli · Answer

What should await cancellation

tad · Answer

the `repeatOnLifecycle` block is cancelled when the lifecycle exits the STARTED state it is stopped

uli · Answer

Just call CoroutineScope launch session recordBackgroundTime

uli · Answer

Would that do what you want

tad · Answer

Yes but `withContext NonCancellable ` is working and feels like the correct thing to do here

Nick Allen · Answer

Be careful launching work into some non child scope It s easy to run into issues like invokeOnCompletion code that doesn t wait for all the work because some work is not part of that scope

ephemient · Answer

does your cleanup do the right thing if the lifecycle re enters STARTED while your STOPPED handler is running

uli · Answer

True But we exactly want that work not to be part of the scope I guess

tad · Answer

< ephemient> I don t think that s possible with `NonCancellable` unless I m not understanding what happens here

tad · Answer

I ll try breaking it by adding a delay

ephemient · Answer

actually I didn t see the `runBlocking` that is dangerous inside of coroutine context will deadlock if you have anything that wants to `withContext Main `

ephemient · Answer

if you can tolerate asynchronicity this is a case where `GlobalScope launch ` might be a reasonable but should also be used with caution

tad · Answer

< ephemient> Interesting adding a 5 second delay inside `NonCancellable` and presumably with GlobalScope the handler ends up running after re starting the activity

tad · Answer

So I ll need to serialize or lock if I care about this edge case

ephemient · Answer

or somehow cancel which itself is tricky yes

uli · Answer

< ephemient> you warn ofa new scope and suggest to use GlobalScope

tad · Answer

That would allow cancellation if I hold onto the Job yeah

uli · Answer

Same for a custom scope

tad · Answer

but the session timeout is 2 minutes so racing on the recorded time is not an issue unless a write takes longer than that

ephemient · Answer

< uli> I mean that GlobalScope may be desired if the cleanup should not be cancelled but care must be taken in all cases

uli · Answer

What would GlobalScope improve over s custom scope

tad · Answer

what parent would the custom scope have though

tad · Answer

if the parent is the lifecycle it will be cancelled before the write succeeds

uli · Answer

Sorry that was < Nick Allen>

uli · Answer

Warning of a custom scope

uli · Answer

Any way it is preferable to use CoroutineScope over GlobalScope But the idea is basically the same

Nick Allen · Answer

Curious would you rather cancel the previous recordBackgroundTime action or cancel the new recordBackgroundTime action

ephemient · Answer

CoroutineScope which gets lost when the containing object is destroyed is not better than GlobalScope if you need the coroutine to keep running

ephemient · Answer

whether that s the case or not depends on usage though

uli · Answer

True You might want to hold on to it

tad · Answer

< Nick Allen> I would cancel the previous job but it s moot in this case because the logic will default to a locked session if we race on `recordBackgroundTime`

Nick Allen · Answer

CoroutineScope over GlobalScope lt I also disagree Need to be careful with either

tad · Answer

also if writing to disk takes 2 minutes then this app will have other problems slightly smiling face

uli · Answer

With a property Val cleanupScope = CoroutineScope SupervisorJob Excuse the layout I am on mobile

ephemient · Answer

a property is also not helpful if the containing object gets destroyed

uli · Answer

True again

uli · Answer

Then repository singleton application property But any solution that allows to handle exceptions

uli · Answer

As a habit

gildor · Answer

``` gt This is a suspending function that performs I O and needs to complete ``` If your function is suspend there is no reason to warp it to runBlocking you block your main thread just remove runBlocking and it will work

tad · Answer

That s not correct since this is happening after `awaitCancellation ` the function is called suspended as it uses `withContext <http Dispatchers IO|Dispatchers IO> ` internally and the parent scope is cancelled before the function performs the save

gildor · Answer

Ah yes I see now await cancellation

gildor · Answer

Probably better would be avoid blocking and make recordBackgroundTime non suspend which returns immediately and under the hood has own scope to do all required io Otherwise blocking thread + delaying cancellation doesn t look right though it may be not an issue on practice in particular case but may cause issues later because of blocked Main thread even cause deadlock