Hey all ! A question / discussion :slightly_smiling_face: ```private var job: Job? = null s...

# coroutines

[Melih Aksoy]

Hey all ! A question / discussion 🙂

private var job: Job? = null
        set(value) {
            println("Setting value")
            field = value
        }

        job = lifecycleScope.launch() {
            println("Started")

            try {
                println("Try")
            } catch (e: CancellationException) {
                println("Catch")
            } finally {
                println("Finally")
            }
        }

prints

Started
Try
Catch
Finally
Setting value

in order.

Which means when using default coroutine start, launch returns job reference after contents are executed ( if execution is fast enough ). So there’s no guarantee when you’ll be handled job reference when you do the assignment. I didn’t find any mention of this in any docs, but I was expecting it to at least wait for reference to be handled before starting execution 🤔

This is probably troublesome in scenarios if you do an if ( job != null ) return check or similar ( clear in finally ( finally { job = null } ). You may end up job being assigned and not getting cleared.

P.S. Using CorotuineStart.LAZY followed by job?.start() resolves this issue, I’m just asking if is this expected from default implementation 🤔 ?

[wasyl]

This is Android, right? It might be because the default UI dispatcher uses an immediate scheduler, which executes the contents in-place if the coroutine is already started on the UI thread (unless a suspension point is hit)

[ephemient]

IIRC lifecycleScope uses Dispatchers.Main.immediate, so if you're already on the main thread it'll run immediately

[ephemient]

*what Łukasz said

[Melih Aksoy]

yeah, spot on it’s android 😄

[ephemient]

also it seems bad to rely on that ordering anyway, if it's a multi-threaded dispatcher then there's still a chance the job could complete before you get done assigning the field

[ephemient]

btw, why do you want to clear the job anyway?

[Melih Aksoy]

yeah, I came up with snippet just for demonstration, to be honest I was mentally convinced that assignment should be done before execution 😄

[Melih Aksoy]

to prevent multiple invokes of a function, eg

fun something() {
   if ( job != null ) return

   job = launch { ... }
}

[Melih Aksoy]

or cancelling previous job and reassigning ( for cases like refresh spam etc. )

[Melih Aksoy]

it was working just fine until I hit the point where I return from the launch early by adding some checks, it turned into a race condition

[ephemient]

var-ectomy?

val parentJob = Job(lifecycleScope.coroutineContext.job)

parentJob.cancelChildren() // cancel previous jobs without races
lifecycleScope.launch(parentJob) {
    // do work
}