나만을 위한 블로그

코루틴은 가장 먼저 완료되는 코루틴의 결과를 기다리는 select 함수를 제공한다. 또한 여러 채널 중 버퍼에 남은 공간이 있는 채널을 먼저 확인해서 데이터를 보내거나 이용 가능한 원소가 있는 채널로부터 데이터를 받을 수 있는지 확인할 수 있다. 지연되는 값 선택 여러 소스에 데이터를 요청한 뒤 가장 빠른 응답만 얻는 경우를 생각한다. 가장 쉬운 방법은 요청을 여러 비동기 프로세스로 시작하고 select 함수를 표현식으로 사용하고, 표현식 안에서 값을 기다리는 것이다. select 안에선 select 표현식에서 나올 수 있는 결과값을 명시하는 Deferred 값의 onAwait()를 호출한다. 람다 안에서 값을 바꿀 수도 있다. 아래 예에서 비동기 결과값 하나만 리턴하는 걸 볼 수 있는데 select 표..

코루틴끼리의 통신을 위한 기본적 방법으로 채널 api가 추가됐다. 채널은 송신자, 수신자 수에 제한이 없고 채널로 전송된 모든 값은 단 한 번만 받을 수 있다. 채널은 서로 다른 2개의 인터페이스를 구현한 하나의 인터페이스다. SendChannel : 원소를 보내거나 더하거나 채널을 닫기 위해 사용 ReceiveChannel : 원소를 받거나 꺼낼 때 사용 public interface SendChannel { public suspend fun send(element: E) public fun close(cause: Throwable? = null): Boolean } public interface ReceiveChannel { public suspend fun receive(): E public fun..

CoroutineScope 팩토리 함수 CoroutineScope는 coroutineContext를 유일 프로퍼티로 갖는 인터페이스다. public interface CoroutineScope { public val coroutineContext: CoroutineContext } CoroutineScope 인터페이스를 구현한 클래스를 만들고 내부에서 코루틴 빌더를 직접 호출할 수 있다. import kotlinx.coroutines.CoroutineScope import kotlinx.coroutines.Job import kotlinx.coroutines.launch import kotlin.coroutines.CoroutineContext class SomeClass: CoroutineScope {..

코루틴의 중요 기능은 코루틴이 실행돼야(시작, 재개 등) 할 쓰레드(또는 쓰레드 풀)를 결정할 수 있는 것이다. 디스패처로 이 기능을 쓸 수 있다. 코루틴이 어떤 쓰레드에서 실행될지 정하는 건 CoroutineContext다. 기본 디스패처 디스패처를 설정하지 않으면 기본 설정되는 디스패처는 CPU 집약적 연산을 수행하게 설계된 Dispatchers.Default다. 이 디스패처는 코드가 실행되는 컴퓨터의 CPU 개수와 같은 수(최소 2개 이상)의 쓰레드 풀을 갖고 있다. 쓰레드를 효율적으로 쓴다고 가정하면 이론적으로 최적의 쓰레드 개수라고 할 수 있다. 기본 디스패처 제한하기 고비용 작업이 Dispatchers.Default의 쓰레드를 다 써서 같은 디스패처를 쓰는 다른 코루틴이 실행될 기회를 제한하고..

여러 엔드포인트에서 데이터를 동시에 얻어야 하는 중단 함수를 구현할 때 차선책은 뭐가 있을까? 코루틴 스코프 함수 전에 쓰인 방법들 첫 번째 방법은 중단 함수에서 중단 함수를 호출하는 것이다. 문제는 작업이 동시에 진행되지 않는다는 것이다. 하나의 엔드포인트에서 데이터를 얻는데 1초 걸려서 함수가 끝나려면 2초가 걸린다. 두 중단 함수를 동시 실행하려면 각각 async로 래핑해야 한다. 하지만 async는 스코프가 필요하고 GlobalScope 사용은 좋은 방법이 아니다. GlobalScope에서 async를 호출하면 아래 결과가 발생한다. 메모리 누수가 발생할 수 있고 쓸데없이 CPU를 낭비함 코루틴을 단위 테스트하는 도구가 작동하지 않아서 함수 테스트가 어려움 따라서 위 방법 대신 스코프를 인자로 넘..

잡히지 않은 예외가 발생하면 앱이 종료되듯 코루틴도 종료된다. 쓰레드도 종료되지만 차이가 있다면 코루틴 빌더는 부모도 종료시키고 취소된 부모는 모든 자식을 취소시킨다는 것이다. 아래 예에선 예외를 받았을 때 자신을 취소하고 launch가 예외를 부모로 전파한다. import kotlinx.coroutines.delay import kotlinx.coroutines.launch import kotlinx.coroutines.runBlocking fun main(): Unit = runBlocking { launch { delay(1000) throw Error("에러 발생") } launch { delay(2000) println("여기는 출력되지 않음") } launch { delay(500) // 예외..

코루틴의 가장 중요한 기능 중 하나는 취소다. 취소는 정말 중요한 기능이라 중단 함수를 쓰는 몇몇 클래스, 라이브러리는 반드시 지원한다. 단순히 쓰레드를 죽이면 연결을 닫고 해제하는 기회가 없어서 최악의 취소 방식이라고 볼 수 있다. 상태가 여전히 Active인지 확인하는 것도 불편하다. 코루틴이 제시하는 방식은 아주 간단하면서 안전하다. 기본적인 취소 Job 인터페이스는 취소하게 하는 cancel()을 가졌다. 이걸 호출하면 아래 효과를 볼 수 있다. 호출한 코루틴은 첫 중단점(아래 코드에선 delay())에서 Job을 끝냄 Job이 자식을 가졌다면 그 자식들도 취소되지만, 부모는 영향받지 않음 Job이 취소되면 Job은 새 코루틴의 부모로 쓰일 수 있음. 취소된 Job은 Cancelling 상태가 됐..

구조화된 동시성의 중요 특징 3개는 Job 컨텍스트와 관련 있다. Job은 코루틴 취소, 상태 파악 등 여러 곳에서 다양하게 쓰일 수 있다. Job이란 Job은 수명을 갖고 있고 취소할 수 있다. Job은 인터페이스지만 구체적 사용법, 상태를 갖고 있어서 추상 클래스처럼 다룰 수 있다. 아래는 Job의 수명을 나타낸 그림이다. Active 상태에선 Job이 실행되고 코루틴은 Job을 수행한다. Job이 코루틴 빌더에 의해 생성됐을 때 코루틴 본체가 실행되는 상태다. 이 때 자식 코루틴을 실행할 수 있고 대부분의 코루틴은 Active 상태로 시작한다. 지연 시작되는 코루틴만 New 상태에서 시작한다. New 상태인 코루틴이 Active 상태가 되려면 작업이 실행돼야 한다. 코루틴이 본체를 실행하면 Acti..

launch의 정의를 보면 첫 파라미터가 coroutineContext인 걸 알 수 있다. public fun CoroutineScope.launch( context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit ): Job 마지막 인자의 리시버도 CoroutineScope다. 이것은 중요한 개념 같으니 시그니처를 확인한다. public interface CoroutineScope { public val coroutineContext: CoroutineContext } @SinceKotlin("1.3") public ..

중단 함수는 Continuation 객체를 다른 중단 함수로 보내야 하기 때문에 아래가 성립한다. 중단 함수는 일반 함수를 호출할 수 있다 일반 함수는 중단 함수를 호출할 수 없다 때문에 모든 중단 함수는 다른 중단 함수에 의해 호출돼야 한다. 그렇다고 일반 함수에서 아예 중단 함수를 호출할 수 없는 건 아니다. 코루틴 빌더를 통해 일반 함수 안에서 중단 함수를 호출할 수 있다. 코루틴 빌더는 3종류 있고 서로 쓰임새가 다르다. launch runBlocking async launch launch의 작동 방식은 thread 함수를 호출해 새로운 쓰레드를 시작하는 것과 같다. import kotlinx.coroutines.GlobalScope import kotlinx.coroutines.delay imp..