🐸

어제 Async/await 세션을 보았는데요.

Async 함수는 suspend 될 수 있고, suspend 되면 호출한 함수도 suspend 되기 때문에
async 키워드가 붙은 함수를 실행하려면

• 실행하는 함수가 비동기(Async) 이거나
• Async Task Function 안에서 실행

해야만 합니다.

그 중 Async Task Block에 관해 알아보기 위해서 오늘은 이 세션을 보도록 하겠습니다.
Explore structured concurrency in Swift

---

Concurrency

세션 시작전에, Concurrency는 저번 글에서 정리한 용어 입니다.
Queue(작업 대기 행렬)의 작업 처리 방식에 관한 용어 중 하나였죠!

• Serial (직렬)
• Concurrency (동시)

Concurrency는 동시 실행 된다는 뜻으로,
ConcurrentQueue는 들어온 작업을 여러개의 다른 Thread에서 동시에 실행 시킵니다.

---

Structured Programming

Swift 5.5 부터 structured concurrency(구조화된 동시성) 이라는 개념을 사용하여 concurrent Program(동시성 프로그램)을 작성하는 새로운 방법을 소개합니다.

structured Programming.. 구조적 프로그래밍이란 무엇일까?

컴퓨팅 초기에는 control-flow(제어 흐름)가 모든곳에서 이동할 수 있는 일련의 명령으로 프로그래밍이 되었기 때문에 프로그램을 읽기가 어려웠습니다.

하지만! 요즘엔 우리가 사용하는 언어가 control-flow(제어 흐름)을 보다 균일하게 만들기 위해 structured Programming(구조화된 프로그래밍)을 사용하기 때문에 더이상 저렇지 않습니다.

예를들면..

if 블록은 구조화된 프로그래밍을 사용합니다.
중첩된 코드 블락이 위 -> 아래로 이동하는 동안에만 조건부로 실행되도록 지정합니다.

Swift 에서, then Block은 static scoping(정적 범위 지정)도 준수합니다.
즉, 변수명이 블록에 정의된 경우에만 변수명으로 표시됩니다. 또한, 블록안에 정의된 모든 변수의 수명은 블록이 떠날 때 종료됩니다.

결론은, static scope(정적 범위)를 사용한 structured programming은 control-flow(제어 흐름)과 variable lifetime(변수 수명)을 알기 쉽게 만듭니다.

보다 일반적으로, 구조화된 제어흐름은 자연스럽게 순서를 지정하고 함께 중첩될 수 있습니다.
이것이 Structured Programming의 기초 입니다.

우리는 괄호(static scope)를 열고 Top-down으로 코드를 읽으면서 여러 scope들을 왔다갔다 읽는것이 매우 직관적이고 당연하게 여기고 있습니다!

하지만..😱
요즈음 프로그래밍은 asynchronous(비동기적 작업 순서) + concurrent(동시에 여러 작업 실행) 를 특징으로 하기 때문에 structured Programming을 더 쉽게 작성할 수 없었습니다.

왜냐면 어떠한 구조를 어떠한 순서에 맞게 control-flow가 생겨나야 하는데... 비동기와 동시성은 그걸 신경쓰지 않으니까요

---

Structured Programming + asynchronous Code

Asynchronous 한 코드를 어떻게 structued programming 으로 바꾸는지 봅시다.

    /*
     Asynchronous code with completion Handlers is unstructured
     */
    func fetchThumbnail(for ids: [String], completion handler: @escaping ([String: UIImage]?, Error?) -> Void) {
        
        guard let id = ids.first else {
            handler([:], nil)
            return
        }

        let request = URLRequest(url: URL(string: id)!)

        let task = URLSession.shared.dataTask(with: request, completionHandler: { data, response, error in
            if let error {
                handler(nil, error)
            } else if (response as? HTTPURLResponse)?.statusCode != 200 {
                handler(nil, HyunndyError.noImage)
            } else {
                // MARK: 3번
                guard let image = UIImage(data: data!) else {
                    handler(nil, HyunndyError.noImage)
                    return
                }
                
                // MARK: 4번
                image.prepareThumbnail(of: CGSize(width: 40.0, height: 40.0), completionHandler: { thumbnail in
                    guard let thumbnail else {
                        handler(nil, HyunndyError.noImage)
                        return
                    }
                    
                    fetchThumbnail(for: Array(ids.dropFirst()), completion: { thumbnails, error in
                        // .... ad image to thumbnails .....
                    })
                })
            }
        })
        
        task.resume()
    }

이 코드는 structured 하지 않습니다.
왜냐?

CompletionHandler를 사용하는 패턴의 결과로,
이 함수는 error Handling을 위해 구조화된 제어 흐름(structured control-flow)를 사용할 수 없습니다.
왜냐면 CompletionHandler는 그냥 throw된 Error를 처리하는게 의미있기 때문입니다.
(뭔가 제어흐름으로써 관리를 한다는게 아니라 그냥 Error를 던지고 그것만 처리한다의 의미인 것 같습니다)

또..
요 함수는 Array안에 가득들어있는 url과 매칭되는 딕셔너리를 만들어서 CompletionHandler에 넘겨줘야하는데, 그러려면 중첩을 써야합니다.
하지만? CompletionHandler의 형태 때문에 재귀 함수를 쓰고 있지 못합니다.
제어 흐름이 만들어지지 않는다는 소리지요.

이제 이걸 Structured Programming을 기반으로 하는 Async/await 구문을 사용하도록 다시 작성해보겠습니다.

    func fetchThumbnail2(for ids: [String]) async throws -> [String: UIImage] {
        var thumbnails: [String: UIImage] = [:]
        
        for id in ids {
            let request = URLRequest(url: URL(string: id)!)
            let (data, response) = try await URLSession.shared.data(for: request)
            
            try validateResponse(response)
            guard let image = await UIImage(data: data)?.byPreparingThumbnail(ofSize: CGSize(width: 40.0, height: 40.0)) else {
                throw HyunndyError.noImage
            }
            
            thumbnails[id] = image
        }
        
        return thumbnails
    }
    

TA-DA-!
우린 이미 Meet Async/await을 보고왔기 때문에 따로 설명하진 않겠습니다.

여기서 추가로..

• 수 천개의 이미지에 대한 썸네일을 만들어야 하는 경우엔 어떻게 해야할까요? 썸네일을 한 번에 하나씩 처리하는 것은 더이상 이상적이지 않습니다.
• 썸네일을 고정 크기가 아닌 다른 URL에서 다운로드 해야 한다면 어떻게 해야할까요?

이제! 우리는 concurrency를 추가할 수 있으므로, 여러 다운로드가 병렬(parrel)로 발생할 수 있습니다.
우리는 프로그램에 Concurrency(동시성)을 추가하기 위해 Additional Task를 생성할 수 있습니다.

---

Task

Task는 async 함수와 함께 동작하는 Swift의 신기능 입니다.
async한 코드를 실행하기 위한 Fresh한 execution(실행) context를 제공합니다.
각 Task는 다른 execution Task와 관련하여 concurrently(동시에) 실행됩니다.

즉, Task는 App의 실행 컨텍스트(execution contenxt, 작업 플로우)를 나타냅니다.

안전하고 효율적인 타이밍에 parallel(병렬)로 실행되도록 자동으로 스케쥴링 됩니다.
Async 함수를 호출해도 새로운 Task가 만들어지지 않는다는걸 유의해야 합니다! Task는 명시적으로 생성해야 합니다.

structed concurrency는 유연성과 단순성 사이의 균형에 관한 것이기 때문에 Swift에는 몇가지 다른 Task가 있습니다.
함께 보시죠!

Async-let tasks

Async-let 바인딩이라는 새로운 구문 형식으로 생성되는 가장 간단한 Task 입니다.

먼저 기본적인 let Binding은 다음과 같은 Flow로 이루어집니다.

이 Flow에서 다운로드 시간이 오래 걸릴 수 있으니 프로그램이 다운로드를 시작하고 데이터가 실제로 필요할 때 까지 다른 작업을 하길 원합니다.

여기서!! 우리는 기존 let 앞에 async만 붙여주면 됩니다.

이런 형태를 async-let concurrent binding 이라고 합니다.

concurrent binding과 sequential binding은 매우 다릅니다!

concurrent binding을 평가하기 위해, Swift는 new child Task를 생성합니다.
이 작업은 호출한(생성한) Task의 하위 Task 입니다.

모든 Task는 App의 실행 컨텍스트이므로, 2개의 화살표가 한 번에 나옵니다.

• 데이터 다운로드를 즉시 시작하는 Chid Task를 위한 것
• Parent Task를 위한것으로, 변수 결과를 placeholder에 즉시 바인딩 하는 것(다음으로 넘어가기 위해)

Child Task가 Concurrent(동시)에 다운로드를 하는 동안,
Parent Task는 Following statements(다음 동작)를 수행합니다.
하지만!!!! 결과의 실제 값이 필요한 statements에 도달하면 Parent Task는 placeholder을 충족하는 Child Task의 작업이 완료될 때 까지 기다립니다!

두 개의 서로 다른 URL에서 데이터를 다운로드하는 코드를 보며 async-let concurrent binding에 대해 봅시다.

    /// Structured Concurrency with seuquential binding
    func fetchOneThumbnail(withId id: String) async throws -> UIImage {
        let imageReq = URLRequest(url: URL(string: id)!), metaReq = URLRequest(url: URL(string: id)!)
        
        let (data, _) = try await URLSession.shared.data(for: imageReq)
        let (metadata, _) = try await URLSession.shared.data(for: metaReq)
        
        guard
            let size = parseSize(from: metadata),
            let image = await UIImage(data: data)?.byPreparingThumbnail(ofSize: size)
        else {
            throw HyunndyError.noImage
        }
        
        return image
    }

let의 오른쪽에 try await을 사용하는 Sequential Binding(순차 바인딩) 입니다.
try await을 하는쪽에서 Error나 Suspend가 Observing 되는 위치이기 때문입니다.
여기서는 download가 순차적으로 진행됩니다.

하지만 우린 요! 다운로드를 동시에(Concurrently) 수행하고 싶습니다.
Concurrent를 구현하려면 어떻게 해야하죠? Task를 추가해야합니다.
우리는 방금 뭘배웠죠? async-let Task요!

    /// Structured Concurrency with async-let concurrent binding
    func fetchOneThumbnail2(withId id: String) async throws -> UIImage {
        let imageReq = URLRequest(url: URL(string: id)!), metaReq = URLRequest(url: URL(string: id)!)
        
        /// async let을 쓰면 이제 다운로드가 Child Task에서 발생하므로 더이상 오른쪽에 try await을 사용하지 않습니다.
        /// 하위 Task, 상위 Task에서 동시에 바인딩된 변수를 """사용할 때"""" Parent Task에서만 Error나 suspend가 Observing 됩니다.
        async let (data, _) = URLSession.shared.data(for: imageReq)
        async let (metadata, _) = URLSession.shared.data(for: metaReq)
        
        /// 따라서 사용하는 부분에 try await을 붙입니다.
        guard
            let size = parseSize(from: try await metadata),
            let image = try await UIImage(data: data)?.byPreparingThumbnail(ofSize: size)
        else {
            throw HyunndyError.noImage
        }
        
        return image
    }
    

async-let을 통해 concurrency Binding으로 바뀐 코드 입니다.

이제 다운로드는 Child Task들에서 동시에 발생합니다.
따라서 Error나 Suspend가 Child Task에서 발생하지 않기 때문에, async let을 붙인 변수 옆에서 try await을 지워줍니다.

그럼 어디 넣어주느냐?
위에 Flow 기억나시죠?
Parent Task와 Child Task가 동시에 Binding한 값을 실제로 쓰는 부분에서 Error나 Suspend를 Observe 하고 있습니다.
따라서 값을 실제로 사용하는

       guard
            let size = parseSize(from: try await metadata),
            let image = try await UIImage(data: data)?.byPreparingThumbnail(ofSize: size)

이곳에 넣어줍니다.

---

Structured task guarantees

여기까지 말한 Child Task는 실제로 Task Tree 라는 계층 구조의 일부입니다.
하나의 Asynchronous 함수에서 다른 함수로 호출할 때 마다, 동일한 Task가 호출을 실행하는데 사용됩니다.

    /// Structured Concurrency with async-let concurrent binding
    func fetchOneThumbnail2(withId id: String) async throws -> UIImage {
        let imageReq = URLRequest(url: URL(string: id)!), metaReq = URLRequest(url: URL(string: id)!)
        
        /// async let을 쓰면 이제 다운로드가 Child Task에서 발생하므로 더이상 오른쪽에 try await을 사용하지 않습니다.
        /// 하위 Task, 상위 Task에서 동시에 바인딩된 변수를 """사용할 때"""" Parent Task에서만 Error나 suspend가 Observing 됩니다.
        async let (data, _) = URLSession.shared.data(for: imageReq)
        async let (metadata, _) = URLSession.shared.data(for: metaReq)
        
        /// 따라서 사용하는 부분에 try await을 붙입니다.
        guard
            let size = parseSize(from: try await metadata),
            let image = try await UIImage(data: data)?.byPreparingThumbnail(ofSize: size)
        else {
            throw HyunndyError.noImage
        }
        
        return image
    }
    

따라서, fetchOneThumbnail함수는 해당 Task의 모든 attribute를 상속합니다.
async-let과 같이 새로운 Task를 만들 때, 현재 함수가 실행중인 Task의 자식이 됩니다.

Task는 특정 function의 child는 아니지만, 그들의 수명은 해당 function의 범위로 지정될 수 있습니다.

Task Tree는 트리구조이기 때문에 하위 Task가 모두 완료되어야만 상위 Task가 완료될 수 있습니다.

이 규칙은 자식 Task가 awaited되지 않도록 하는 비정상적인 제어 흐름에도 적용됩니다.
이게 뭔말이야?

        guard
            let size = parseSize(from: try await metadata),
            let image = try await UIImage(data: 

코드를 보면, data를 가져오는 다운로드를 먼저 시작했는데, metaData 작업부터 기다립니다.
근데 만약 data를 다운로드하는데서 오류가 나면 어쩔까요?
Parent Task는 data에서 오류가 나도, metaData 작업을 그냥 취소 상태로 만들어버린다음 fetchThumbnail 함수가 끝날 때 까지 기다립니다.
Task를 Cancel로 마킹해도 Stop 시키진 않습니다. 그냥 결과가 이제 필요하지 않다고 합니다.

상위 Task가 실패하면 하위 Task는 자동으로 취소됩니다.
결과적으로 data를 다운로드 하는 Task가 에러를 발생시키면, 해당 작업은 Cancel로 표시됩니다.
fetchThumnnail() 함수는 마지막에 에러를 발생시키면서 종료됩니다.

음.. 이런

• 상위 Task에서 Error가 발생하면 하위 Task와 상위 Task 모두 Cancel 상태가 된다.
• 모든 Task가 Cancel 되거나 Finish되면 호출한 Function도 모두 끝나길 기다리다가 에러를 방출하며 종료된다.

(이해한게 맞는지 모르겠지만) 이 보장은 structured Concurrency의 기본입니다.
ARC가 메모리 수명을 자동으로 관리하는 것과 마찬가지로 Task의 수명주기도 자동으로 관리합니다.

여기까지 Cancellation의 전파에 관한 내용입니다.
하지만 언제 Task가 Stop 됩니까?
Task가 트랜잭션 중이거나, 네트워크 연결이 열려있는 경우 Stop 시키는건 좋지 않습니다.
-> 요게 바로 Cancellation이 cooperative한 이유 입니다.

Cancellation is cooperative

• Task는 cancel됐다고 바로 stop 하지 않습니다.
• cancellation은 어디서나 체크될 수 있습니다.
• API를 cancellation을 염두해두고 디자인하세요.

Cancellation..그래.
Task가 어떻게든 Error가 나서 Cancel 될 수 있다고 합시다.
그럼 이걸 우리가 어떻게 추적할 것인가!

    /// Cancellation checking
    func fetchThumbnails(for ids: [String]) async throws -> [String: UIImage] {
        var thumbnails: [String: UIImage] = [:]
        for id in ids {
            /// Throws an error if the task was canceled.
            /// Task가 취소된 경우 Error을 발생시켜 for 루프를 탈출시킵니다.
            /// Task가 cancel된 경우 쓸모없는 통신을 계속해서 App이 crash 나게 냅두고 싶지 않습니다.
            try Task.checkCancellation()
            if Task.isCancelled { break }
            thumbnails[id] = try await fetchOneThumbnail(withId: id)
        }
        return thumbnails
    }

try Task.checkCancellation()
if Task.isCancelled
등으로 Task가 Cancel된 것을 감지하여 무의미한 Task 실행을 하지 않을 수도 있습니다.

---

🐸

음..솔직히 여기서부터 약간 멘붕왔습니다.
난 그냥...Async/await 세션에 나왔던 Task { } 가 궁금했을 뿐인데...
왠? ㅠㅠ 이게 모야? ㅠㅠ 스키 초급 코스 내려왔는데 갑자기 중급코스 내려가라는 기분..?
아무튼 여기서부터는 이해보단 정말..그냥 WWDC 내용을 뇌에 우겨넣기 위해 어거지로 학습한 내용을 나열합니다..

---

Group Task

async-let Task는 사용가능한 concurrency가 고정되어있을 때 사용합니다.
예를들어서..

    /// Async-let is for concurrency with static width
    func fetchThumbnails3(for ids: [String]) async throws -> [String: UIImage] {
        var thumbnails: [String: UIImage] = [:]
        for id in ids {
            thumbnails[id] = try await fetchOneThumbnail2(withId: id)
        }
        
        return thumbnails
    }

이 함수에서는

• async let (data, _) = URLsession ~
• async let (metadata, _) = URLSession ~

2개의 Child Task가 생성됩니다.
그리고 다음 루프가 돌기 전에 이 2개의 Task가 완료되야합니다.

하지만..
우리가 모든 썸네일을 그냥 한 번에 다운로드하고 싶다면?
여기서는 ids라는 정적 배열이 있었지만, 루프가 몇 개 돌지도 모르고 만약 그게 엄청 많아진다면?

이런 상황에 대응할 수 있는게 Task Group 입니다.

Task Group은 dynamic한 양의 concurrency를 제공하도록 설계된 structured concurrency의 한 형태입니다.

Task Group은 withThrowingTaskGroup 함수로 호출하여 만들 수 있습니다.

    func taskGroupFetchThumbnail(for ids: [String]) async throws -> [String: UIImage] {
        var thumbnail: [String: UIImage] = [:]
        
        try await withThrowingTaskGroup(of: Void.self, body: { group in
            for id in ids {
                group.addTask {
                    thumbnail[id] = try await self.fetchOneThumbnail2(withId: id)
                }
            }
        })
    }

withThrowingTaskGroup 함수는
Error을 Throw 할 수 있는 Child Task를 만들기 위해 범위가 지정된 group object를 만들어줍니다.
Group { } 을 나가면 Task의 수명이 다하고,
블록 내부 안에 for-in loop를 배치했기 때문에 dynami한 양의 Task를 동시에 생성할 수 있습니다. 순서와 상관없습니다.

하지만 저 코드는 컴파일 에러를 발생합니다.

thumbnail 딕셔너리는 한 번에 두 개 이상의 액세스를 처리할 수 없는데 Task Group 안에서는 동시에 Task가 많이 생겨나므로 data race 컴파일 에러가 발생하는 것 입니다!

과거에는 이 오류들을 직접 찾았어야 했는데, 지금은 컴파일러가 알려준다는데요.

@Sendable

이것 덕분 입니다.
data-race safety 라는 개념인데..
Task의 생성은 @Sendable 클로저에서 실행됩니다.
@Sendable 클로저 본문은 변경 가능한 변수를 캡쳐하는것이 제한됩니다.
왜? Task가 실행된 후 수정 될 수 있으니까요.
이 말은... Task 안에서 캡쳐된 값은 공유하기에 안전한 value Type, actors, 자체 동기화를 구현한 class 객체 같은 것이어야 한다는 것입니다.

다시 돌아와서!
코드를 수정합니다.

    // A task group is for concurrency with dynamic width
    func taskgroupFetchThumbnail(for ids: [String]) async throws -> [String: UIImage] {
        
        var thumbnails: [String: UIImage] = [:]
        try await withThrowingTaskGroup(of: (String, UIImage).self, body: { group in
            for id in ids {
                group.addTask {
                    return (id, try await self.fetchOneThumbnail2(withId: id))
                }
            }
    
            // 이 for-await 루프는 완료된 순서대로 자식 작업에서 결과를 가져옵니다.
            for try await (id, thumbnail) in group {
                thumbnails[id] = thumbnail
            }
        })
        return thumbnails
    }

withThrowingTaskGroup(of: ~)
에 들어가는게 group Task에서 반환되는 타입이었군요.

Group Task안에서 루프 안에 있는 많은 양의 Task를 동시에 생성해서 한 번에 만들어서 리턴시키고,
밖에서의 for-in 루프는 순차적으로 thumbnail 딕셔너리를 세팅합니다.

만약에 Error가 발생하면 async-let 처럼 종료되지 않고 cancel, wait하다가 함수 종료될 때 같이 끝난다고 합니다.

---

여기까지 Scoped(범위가 지정된) Structured(구조화된) Task를 제공하는

• async-let
• group Task

방법이었습니다.

다음은 unStructured Task 입니다.
왠지 이게 제가 찾던 Task일 것 같은 예감이 듭니다!

---

Unstructured Task

앱을 구현하면서.. Task가 항상 명확한 계층 구조에 속한식으로만 구현되진 않습니다.
오히려 훨씬 더 많은 수동관리가 필요한 대신 유연성을 제공하는 Unstructured한 방식이 더 많죠.

Not all tasks fit a structured pattern

제일 흔한 상황은,
non-async 코드에서 async 계산을 수행하기 위해 Task를 시작하려는 경우 Parent Task가 전혀 없을 경우 입니다.

또는,
내가 원하는 Task의 수명이 single scope 또는 single function이 아닐수도 있죠.
예를 들어, 객체를 active 상태로 전환하는 메서드 호출에 대한 응답으로 Task를 시작한 다음 객체를 deactivate 상태로 전환하는 메서드 호출에 대한 응답으로 Task를 취소하고 싶을 수도 있습니다.

이것은 AppKit 및 UIkit에서 델리게이트 객체를 구현할 때 많이 나타납니다.

예시를 보시죠!

    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        let thumbnails = await fetchThumbnail2(for: ids)
    }

CollectionViewCell에 네트워크에서 가져온 썸네일을 가져와 띄우려고 합니다.
하지만 Delegate 메서드는 async 하지 않기 때문에 async 함수를 호출할 수 없습니다.
MainThread에서 동작하기 때문에 await할 수 없기 때문이죠 ㅜ.ㅜ

UI 작업은 Main Thread에서 발생해야하며, Swift는 @MainActor라고 표기함으로써 이걸 보장합니다.
만약에 우리가 Delegate 메서드 안에서 Task 를 생성한다면, 우리는 이 Task가 Main Actor에서 실행되길 원합니다.
이 때! unstructured Task를 만들 수 있습니다.

    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        let thumbnails = await fetchThumbnail2(for: ids)
    }

이 코드를 unstructured Task를 사용해 async 처리를 할 수 있게 해볼게요.

    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        Task {
            let thumbnails = try await fetchThumbnail2(for: ids)
            display(thumbnails, in: cell)
        }
    }

async 관련 처리를 Task안에 넣었습니다.
이렇게 하면 무슨일이 일어나냐면..

Task를 생성하는 시점에 도달하면 Swift는 original scope와 동일한 Actor에서 실행되도록 스케줄링 합니다. (Task는 자동으로 스케줄링)
이 경우에는 MainActor에서 실행되겠죠?

썸네일을 받아오는 Task는 Delegate 함수 안에서 Main Thread를 차단하지 않고 기회가 있을 때 Main Thread에서 실행됩니다.
이런식으로 Task를 실행하면 구조화된 코드와 구조화 되지 않은 코드 사이의 중간지점을 제공할 수 있습니다.

특징

이렇게 직접 생성된 Task의 특징이 있는데요.

• 직접 생성된 Task는 이미 시작되어있는 Actor를 상속하며, Group Task, async-let과 마찬가지로 original Task의 우선순위 및 기타 특성도 상속합니다.
• Lifetime is not confined to any scope -> 범위에 상속되지 않습니다.
• Can be launched anywhere, even non-async functions. 어디서나 만들 수 있습니다. 심지어 non-async 함수에서도요!
• 하지만 Structured Concurrency가 자동으로 처리해줬던것들을 수동으로 관리해야합니다.
• Must be manually cancelled or awaited
• 취소 및 오류는 자동으로 전파되지 않으며, 명시적인 조치를 취하지 않는 한 자업 결과를 암시적으로 기다리지 않습니다.

Must be manually cancelled or awaited

    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        Task {
            let thumbnails = try await fetchThumbnail2(for: ids)
            display(thumbnails, in: cell)
        }
    }

그래서!!!! 저 위 예시에서 collectionView를 표기할 때 썸네일이 다운로드 되기도전에 스크롤되면 해당 Task도 취소해야 합니다.
저 Task는 unscoped task이기 때문에 Task cancel은 자동이 아닙니다.

따라서..

    var thumbnailTasks: [IndexPath: Task<Void, Error>] = [:]
    
    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        thumbnailTasks[item] = Task {
            defer { thumbnailTasks[item] = nil } // defer가 뭐징
            let thumbnails = try await fetchThumbnail2(for: ids)
            display(thumbnails, in: cell)
        }
    }

이렇게 저장해뒀다가!!

    func collectionView(_ collectionView: UICollectionView, didEndDisplaying cell: UICollectionViewCell, forItemAt indexPath: IndexPath) {
        thumbnailTasks[indexPath]?.cancel()
    }

cancel 시킬 수 있습니다.

---

Detached Tasks

위에서 살펴본 Task는 모두 Task는 모두 생성되면 original scope의 특성을 상속하는 특징이 있었는데요.
아무것도 상속하고 싶지 않은 Task도 있습니다.
완전한 자율성을 위해...

cancel, await를 manually하게 관리해줘야하며 lifeTime이 unscope합니다.
originating context에서 아무것도! 상속하지 않습니다.

서버에서 썸네일을 가져온 후 나중에 가져오려고 할 때 네트워크에 다시 연결되지 않도록 로컬 디스크 캐시에 기록하려고 한다고 가정해보자.
캐싱은 메인 액터에서 발생할 필요가 없으며 모든 썸네일 가져오기를 취소하더라도 가져온 썸네일을 캐시하는것이 여전히 유용합니다.

    func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt item: IndexPath) {
        let ids = getThumbnailIds(for: item)
        thumbnailTasks[item] = Task {
            defer { thumbnailTasks[item] = nil } // defer가 뭐징
            let thumbnails = try await fetchThumbnail2(for: ids)
            display(thumbnails, in: cell)
            
            /*
             Datached Task
             로컬 디스크에 캐싱하는거니까 낮은 우선순위의 백그라운드에 지정합니다.
             */
            Task.detached(.background, operation: {
                writeToLocalcache(thumbnails)
            })
        }
    }

요런식으로 Detach Task를 생성할 수 있습니다.

---

Task 총 정리

---

느낀점

드디어..!!
드디어 끝났다..!!!!
이 27분 54초 짜리 영상을 3일 동안 정리?.. 받아 적었다.

퇴근 후에 스터디를 하는데...왜 10분 정리하면 2시간 지나있고 그러냐고 ㅠㅠㅠ
이제서야 meet async/await 했는데 Unstructured Task 하나 알려다가 체할뻔했다.

어쨋든 포기하지 않았어...
이 세션은 async/await에 대한 공부를 더 한 다음에 다시 한 번 봐야겠다.

음 결론적으로 내가 궁금했던 Task는
Unstructured task 였고,
음..지금으로써는 다른 Task를 쓸 수 있을지 모르겠다.
예제코드를 좀 더 학습해야 될 것 같다.

다음 학습을 하기전에..
asyn/await에서 배운 예제들을 다시 정리하고
내가 지금쓰는 프로젝트에서 이걸 어떻게 녹일 수 있을지 고민해보고..!
alamofire와는 어떻게 합쳐질지 학습해봐야겠다.

Actor, defer의 개념도.
끝!