Coroutine context and dispatchers

https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html

Coroutine context and dispatchers | Kotlin

위 링크를 공부하며 남기는 기록이다.

 

코루틴에서 사용하는 context는 대표적으로 CoroutineContext 타입이 있다. 이번 페이지에서는 이전에 봤던 Job 객체와 Dispatcher를 살펴보겠다.

 

Dispatchers and threads

coroutine context에는 coroutine dispatcher도 포함되는데 해당 코루틴을 실행할 때 사용하는 쓰레드다. dispatcher로 특정 쓰레드를 다룰 수 있으니 코루틴의 실행을 제어할 수 있다. dispatch의 뜻이 보내다라는 의미인데 쓰레드 풀로 보내거나 아니면 안보내고 실행하거나 둘 중 하나를 의미한다고 이해했다.

 

코루틴 빌더들(lauch, async)은 coroutine context를 선택적으로 인수에 넣을 수 있다. 컨텍스트를 명시적으로 사용한다는 말은 쓰레드를 구분해서 사용하겠다라는 의미같다.

    launch { // context of the parent, main runBlocking coroutine
        println("main runBlocking      : I'm working in thread ${Thread.currentThread().name}")
    }
    launch(Dispatchers.Unconfined) { // not confined -- will work with main thread
        println("Unconfined            : I'm working in thread ${Thread.currentThread().name}")
    }
    launch(Dispatchers.Default) { // will get dispatched to DefaultDispatcher 
        println("Default               : I'm working in thread ${Thread.currentThread().name}")
    }
    launch(newSingleThreadContext("MyOwnThread")) { // will get its own new thread
        println("newSingleThreadContext: I'm working in thread ${Thread.currentThread().name}")
    }

이걸 실행해보면 1,2,3,4가 2,3,1,4 순서대로 출력된다. 디스패처를 지정하지않으면 부모 코루틴의 컨텍스트를 받는다. 여기서는 제일 바깥에 runBlocking(main 쓰레드에서 돌아감)이 있으니 1번의 쓰레드가 메인이다. 

 

디폴트 디스패처는 JVM에 있는 공유 쓰레드 풀에서 돌아간다. 디스패처에 다른 컨텍스트가 지정되지않은 경우 사용된다. 이 디스패처에서 사용할 병렬처리수준은 CPU코어 개수를 따라가지만 최소 2개로 병렬처리를 한다.

 

마지막 코루틴에서 디스패처는 코루틴을 사용하기 위한 쓰레드를 하나 생성한 것이다. 전용 쓰레드를 할당하는 것은 리소스를 많이 차지하기 때문에 실제로는 close로 해당 코루틴 디스패처를 닫아주거나 최상위 변수로 지정해 앱 전체에서 사용하게 해야한다.

CoroutineDispatcher

모든 디스패처가 확장해서 사용하는 추상클래스이다. kotlinx.coroutines에 있는 디스패처 목록은 다음과 같다.

 

Dispatchers.Default:

디스패처에 따로 context가 지정되지않으면 이게 사용된다. 공유 백그라운드 쓰레드의 공용 풀을 사용하기 때문에 CPU리소스가 많이 필요한 작업에 적합하다.

Dispatchers.IO:

요청할 때 생기는 쓰레드의 공유 풀을 사용하고 파일입출력, 소켓입출력 차단과 같은 작업에 사용된다. 이걸 Offloading이라고 하는데 CPU가 TCP/IP 프로세싱하는 걸 막아서 성능을 올리는 작업이다.

Dispatchers.Unconfined:

코루틴 빌더가 반환되는 첫 지점까지 코루틴을 실행한다. 중단된 코루틴은 해당 중단 함수에서 사용하는 쓰레드에서 재시작된다. 밑에 조금 더 자세히 정리하였다.

 

private 쓰레드 풀은 newSingleThreadContext, newFixedThreadPoolContext로 생성할 수 있다. 

Unconfined Dispatcher vs Confined Dispatcher

unconfine은 제한이 없는이라는 의미를 가진다. unconfined 디스패처는 코루틴을 호출한 쓰레드에서 시작해 첫 suspend지점까지 실행한다. 지연이 끝나면 코루틴을 재개한다. 이러한 작업은 중간에 멈추기 때문에 cpu time을 소비하거나 ui update를 업데이트하는 작업에는 적절하지않다. unconfined 디스패처도 기본적으로 외부 코루틴스코프를 상속받아 사용한다. 그중 runBlocking은 특히 호출용 스레드로 제한되는데 이걸 상속받은 unconfined 디스패처는 FIFO 스케줄링처럼 사용된다고 한다.

launch(Dispatchers.Unconfined) { // not confined -- will work with main thread
    println("Unconfined      : I'm working in thread ${Thread.currentThread().name}")
    delay(900)
    println("Unconfined      : After delay in thread ${Thread.currentThread().name}")
}
launch { // context of the parent, main runBlocking coroutine
    println("main runBlocking: I'm working in thread ${Thread.currentThread().name}")
    delay(1000)
    println("main runBlocking: After delay in thread ${Thread.currentThread().name}")
}

프린트문을 1,2,3,4라고 할때 1,3,2,4라고 대답하는게 일반적이다. 이건 unconfined가 없어도 당연한 결과인데 다른 점은 unconfined 디스패처의 두번째 프린트문이다. 

Unconfined      : After delay in thread kotlinx.coroutines.DefaultExecutor

이런 메시지가 나온다. 첫번째 프린트문을 출력할 때 사용한 쓰레드를 사용하지않고 있는 모습을 보여주는데 이건 delay가 사용하는 기본 쓰레드를 받아서 사용하고 있는 것이다. 그럼 원래 쓰레드를 사용하지않는다는 말인데 unconfined dispatcher를 사용하는 목적은 일부작업 즉시수행이다. 딜레이 함수를 거치면서 suspend걸린순간 외부 코루틴을 재개하기 때문에, 나중에 실행할 작업이 있는 코루틴에서는 사용하면 안된다.

Job in the context

job도 컨텍스트의 일부인데 아래와 같이 해당 job의 context를 추출할 수 있다.

println("My job is ${coroutineContext[Job]}")

여기서 새롭게 알게된 사실인데 isActive 프로퍼티가 coroutineContext[Job]?.isActive == true의 단축어이다. 현재 코루틴을 추출해 isActive가 true인지 확인하는 과정을 줄여둔 것이다.

Children of a coroutine

코루틴이 다른 코루틴 안에서 실행되면 외부 코루틴의 context를 상속받는다. 그 말은 내부 코루틴의 Job이 외부 코루틴 Job의 자식이 된다는 말이다. structured concurrency에 근거해 부모 코루틴이 취소되면 그대로 자식까지 전파되어 다 취소된다. 하지만 이 전파형상은 override 상황에서는 적용되지않는다.

 

내부 코루틴에서 명시적으로 다른 스코프를 지정할 경우 부모 스코프를 상속받지 않는다. 다른 예로는 아래 코드가 있다.

val request = launch {
    launch(Job()) { 
        println("job1: I run in my own Job and execute independently!") //1
        delay(1000)
        println("job1: I am not affected by cancellation of the request") //2
    }
    launch {
        delay(100)
        println("job2: I am a child of the request coroutine") //3
        delay(1000)
        println("job2: I will not execute this line if my parent request is cancelled") //4
    }
}
delay(500)
request.cancel()
println("main: Who has survived request cancellation?") //5
delay(1000)

lauch 안에 있는 Job은 다른 곳에서 온 Job이다. 이걸받는 순간 외부 코루틴 스코프를 상속 받지않는다. 1,2,3,4,5의 출력 순서는 1,3,5,2다.

1,2 가 들어있는 코루틴은 외부의 Job을 상속받았기 때문에 request에 들어가는 코루틴 스코프와는 독립적이다. 따라서 cancel의 영향이 없다. 

Parental Resposibilities

부모 코루틴은 자식 코루틴이 끝날 때 까지 기다린다. 이것 역시 구조적 동시성에 따른 규칙일 것이다. 

fun main() = runBlocking<Unit> {
    val request = launch {
        repeat(3) { i ->
            launch  {
                delay((i + 1) * 200L) // variable delay 200ms, 400ms, 600ms
                println("Coroutine $i is done")
            }
        }
        println("request: I'm done and I don't explicitly join my children that are still active")
    }
    request.join()
    println("Now processing of the request is complete")
}

여기서 맨 마지막 출력문은 Now~문장이다. join()은 request가 끝나는 것을 기다렸다가 실행되기 때문에 request의 자식 코루틴이 모두 실행되고나서 join()을 진행한다.

Combining context elements

launch(Dispatchers.Default + CoroutineName("만두")) {
    println("I'm working in thread ${Thread.currentThread().name}")
}

//출력
I'm working in thread DefaultDispatcher-worker-1 @만두#2

CoroutineName은 디버깅용 context라고 할 수 있는데 디버그 로그에 해당 이름을 갖고 로그가 출력된다. 

 

Coroutine scope - Class에서 쓴다면

코루틴스코프 인스턴스를 생성해서 생명주기를 액티비티에 제한할 수 있다. CoroutineScope(), MainScope()로 인스턴스를 배정해 코루틴 스코프를 액티비티 클래스 내부에서 만들 수 있다. MainScope에 주목해야하는데 Dispathcers.Main을 기본 디스패처로 사용하고 UI를 그리는 데 사용되는 스코프이기때문이다.

 

코루틴 스코프를 만들고 나면, 이제 스코프인스턴스.launch{ }와 같은 형태로 코루틴을 실행할 수 있다. 

    fun doSomething() {
        // launch ten coroutines for a demo, each working for a different time
        repeat(10) { i ->
            mainScope.launch {
                delay((i + 1) * 200L) // variable delay 200ms, 400ms, ... etc
                println("Coroutine $i is done")
            }
        }
    }

이렇게 만든 클래스 메서드는 액티비티 인스턴스를 이용해 실행할 수 있는데 액티비티 인스턴스를 destroy하면 인스턴스 내부 코루틴도 cancel된다.

 

 

"댓글, 공감 버튼 한 번씩 누르고 가주시면 큰 힘이 됩니다"