allen

아 네네, 해당 내용에서느 직관적인 이해를 위해서.. 편의상 그렇게 설명드리고 있는 것 뿐입니다 ! 비동기(async) 함수로 구현하시면, 백그라운드 쓰레드 어디에서도 실행될 수 있습니다. Task가 3번 쓰레드라고 가정하고, LibraryAccount 액터가 2번 쓰레드라고 가정하면, (정확하게 보자면) 비동기 readAny 함수의 경우, 비동기 함수이기 때문에 백그라운드 쓰레드(예를 들어, 4번, 5번, 6번 등) 어떤 곳에서도 실행될 수 있습니다. (async 함수의 특징)&nbsp;그래서 await키워드가 붙여서 실행시켜야 하는 것이기도 하고요. (뭐 예를 들자면, readAny 비동기 함수가 4번에서 실행되었다가 3번 쓰레드에서는 그 일이 마칠때까지 기다리는 것이겠죠.) 해당 내용에서 중요한 포인트는 2번 쓰레드(액터 내부)에서 실행되지 않는다는 내용을 설명드리기 위한 내용이라 최대한 직관적인 이해를 위해 (이미 수업의 앞의 내용들은 이해하시고 계시다는 전제 아래) 설명드리고 있다는 점을 이해 부탁드립니다. :)

20강 Task 내부에서 nonisolated async 호출 예제 질문드립니다

네 안녕하세요 sujinnaljin 님!&nbsp;정확하게 이해하셨고, 저도 그렇게 그림을 그려드렸어요. (강의 내용 17강 5분 7초 ~ 6분 20초 내용의 그림을 다시 보시면 되고, 교재의 경우 p.166 ~ 167 페이지에 내부적으로 여러쓰레드에서 동작할 수 있다고 말씀드리고 있습니다.) 잘 생각해보시면, 그게 앱 단에서 운영체제한테 쓰레드를 빌려쓰는 쓰레드 풀 방식의 개념하고 연결되기 때문에 당연히 그렇다고 보시면 됩니다. (운영 체제 측면에서 보시면, "1개의 쓰레드"도 하드웨어와 긴밀하게 동작하게 만드는 특정한 객체입니다.) (물론 메인 액터/메인 쓰레드의 경우) 프로그램을 실행하는 동안 운영체제가 아예 고정시켜서 특정 쓰레드 1개를 (메인으로 배치시켜서) 고정시키기 때문에, 1개의 앱이 메모리에서 실행될 때 "메인 쓰레드"는 내부적인 쓰레드 객체도 변할 일이 없겠지만, 액터의 경우, (앱 단에서) 1개의 쓰레드만 (직렬적으로) 사용한다고 하더라도, (만약에 바쁘게 일을 계속 해야 한다면) 쓰레드를 운영체제에 반납할 일이 없겠지만, 덜 바쁜 일을 하게되면 당연히 운영체제에 사용하던 쓰레드를 반납하겠죠. (쓰레드풀 방식) 그러다가 액터에서 어떤 일을 수행해야 해서 쓰레드를 다시 운영체제에 빌려온다면.. 당연히 다른 쓰레드 객체이지 않을까요? (물론 우연으로 같은 객체일 수도 있겠죠.) 그런데 그게 어차피 앱단에서는,, 그걸 우리가 신경쓸 일은 아니니까.. (운영체제와 앱 단에서 알아서 일어나는 일일 뿐이니까) 중요한 것이 아니라고 말씀드리는 것이고요! 정확하게 이해하셨습니다 :) 감사합니다 !

19강 Actor 의 동작 관련해 질문드립니다

네 안녕하세요 한재님! 수직정렬이 반듯하다는 의미가 어떤 의미일까요? 가능하시다면, 이미지를 첨부해주시면 좋을 것 같습니다. (Top Constraint 설정 부분은 잘못된 부분이 없어 보입니다.) 혹시나 모르겠지만.. 시뮬레이터에서 한번 실행해 보시겠어요? Xcode 스토리보드에 약간의 오류가 있는 것으로 알고 있어서, 혹시나 스토리보드에서 보이는 화면하고 실제 시뮬레이터에서 실행하는 것과 다르게 보일 수도 있습니다. 실제 시뮬레이터에서 실행하면 정상적으로 실행될 수 있습니다. (단지 스토리보드 표시 오류라서요.. 이 부분 참고 부탁드립니다.)&nbsp;추가적으로 질문을 주셔도 되고, 너무 해결이 안되는 부분이 있으시다면 <a target="_blank" rel="noopener noreferrer nofollow" href="mailto:we.love.code.allen@gmail.com">we.love.code.allen@gmail.com</a> 으로 해당 전체 프로젝트 폴더를 압축해서 보내주시면 해결해드리도록 하겠습니다.&nbsp;감사합니다. :)

기초앱 17강 Contraints 설정 질문입니다.

네 안녕하세요!&nbsp;질문 내용에 대해, 2가지 포인트를 말씀드릴 수 있을 것 같은데요.(1) 여기서 이렇게 Task.detached로 구현되나 그냥 Task로 구현되나, 전혀 상관없이 downloadImage 함수 자체는 액터가 아닌 외부 쓰레드에서 실행되게 됩니다.<pre><code class="language-swift">let task = Task.detached<UIImage, Error> {
 let image = try await downloadImage(from: url)
 return image
}</code></pre><pre><code class="language-swift">let task = Task<UIImage, Error> {
 let image = try await downloadImage(from: url)
 return image
}</code></pre>조금 의아하실 수도 있지만, 왜 그런지 설명드리면.. Task로 구현하시면 actor의 context를 상속받는 것은 맞지만, 실제 downloadImage(from: url) 함수 자체가 액터 내부의 메서드가 아닌 외부의 메서드이고, 해당 함수를 호출하면서, 앞에 await 이라는 키워드가 붙어있다는 것이, 결국엔 나의 쓰레드가 아닌 외부의 쓰레드를 사용한다는 의미라고 보시면 됩니다.(쉽게 한마디로 정리해서 말씀드리면, 비동기 메서드(함수)로 구현되어 있으면, (액터에서 호출하더라도) 액터가 아닌 외부 쓰레드에서 동작합니다.)그래서, 사실 Task 나 Task.detached나 구현하고, 실제 동작하는 것에는 전혀 차이가 없지만.. 여기서 Task.detached를 사용했다는 것은 "외부 쓰레드에서 실행된다는 의미를 조금 더 명확하게 해주기 위함"이라고 보시면 될 것 같습니다.(네 그래서, 위의 내용을 정확하게 이해하시는 것이 먼저 중요한 것 같고요.)&nbsp;(2) 만약에, 위의 (1)번 내용이 아니라고 가정하고, Task를 사용하는 것이 serial executor에서 실행이 된다고 가정을 해서 말씀을 드려도, 재진입 문제가 발생하지 않습니다.<pre><code class="language-swift">let task = Task<UIImage, Error> {
 let image = try await downloadImage(from: url)
 return image
}
 
/// 일단 (완료되지 않은) 작업 상태를 보관
cache[url] = .loading(task)</code></pre>왜냐하면, 바로 아래에 있는 코드인, cache[url] = .loading(task) 때문에 그렇습니다. 쉽게 말씀을 드리면 위의 코드는 바로 아래의 코드와 동일합니다. (Task 안의 비동기적인 작업을 제외하고 생각하시면 쉬워요.)<pre><code class="language-swift">let task = Task<UIImage, Error>{ }
 
cache[url] = .loading(task)</code></pre>작업을 생성하자마자, 동기적으로 일단 cache에 상태를 .loading라고 저장해 놓습니다. 작업 자체를 생성하자마자 저장해놓는 (동기적인) 방식이기 때문에 (물론 작업 안에서는 비동기적인 일이 일어나지만..) 일단 캐시 자체를 바꿔놓았기 때문에 await을 통해 외부에서 접근하더라도 재진입 문제가 발생하지 않습니다.(그래서, "작업(Task)"자체를 생성하고 저장하는(중간에 await키워드가 전혀 들어가지 않는) 동기적인 방식으로 재진입 문제를 해결하는 것이라고 보시면 됩니다.)&nbsp;위의 내용들을 잘 이해해 보시면 좋을 것 같고, 추가적으로 질문이 생기시면 또 질문주세요!감사합니다. :)

Actor에서 Task vs Task.detached 사용 시 재진입 문제 질문

안녕하세요! sujinnaljin 님! 질문주신 내용이 현재 강의의 48강 ~ 52강 내용하고 관련된 내용인데, 이번에 Xcode가 업데이트가 되면서 내부 메커니즘이 이번에 제대로 구현이 되었나 보네요. (Region Based Isolation 관련 내용이예요, <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/swiftlang/swift-evolution/blob/main/proposals/0414-region-based-isolation.md">https://github.com/swiftlang/swift-evolution/blob/main/proposals/0414-region-based-isolation.md </a>) 뒤에 강의에서 내용을 자세히 다루고 있으니.. 강의 내용을 보시면 되고, 그 전에 최대한 직관적이고 간단하게만 말씀드려보면, ValueCounter타입은 값타입이긴 하지만, Task의 클로저 자체는 변수 주소를 캡처해서 사용하기 때문에 valueCounter 변수 주소가 한번 전달(sending)이 되어 버리면, 그 이후의 코드에서는 사용할 수가 없습니다. (그게 Swift Concurrency에서 새롭게 도입한 Shared Mutable State를 다루기 위한 내부 메커니즘이라고 보시면 됩니다.) (즉, 위의 Task를 "1번 Task"라고 이름 붙이기로 하고, 아래 Task를 "2번 Task"라고 이름 붙이기로 하면.. 이미 1번 Task에서 valueCounter를 차지하고 써버리기로 된 것이기 때문에 2번 Task에서는 더이상 valueCounter의 변수에 조차 접근할 수 없어진 것입니다.)<pre><code class="language-swift">func test() {
 var valueCounter = ValueCounter()
​
 Task {// valueCounter의 주소가 Task 내부로 완전 전달 (더이상 아래 코드에서 사용 불가)
 print(valueCounter.increment())
 print(valueCounter.value)
 }
 
 Task { [valueCounter] in // valueCounter 주소에 접근 불가
 var newValueCounter = valueCounter
 print(newValueCounter.increment())
 print(newValueCounter.value)
 }
}</code></pre> 다만, Task와 캡처리스트 순서가 바뀌면 가능한 것입니다. 왜냐면 이번에는 캡처리스트를 먼저 사용했기 때문에, valueCounter변수의 주소가 Task 내부로 완전 전달(sending)이 된 것이 아니기 때문에.. 그 이후의 코드인 Task에서 valueCounter 변수에 접근이 가능한 것입니다.<pre><code class="language-swift">func test() {
 var valueCounter = ValueCounter()
​
 Task { [valueCounter] in // valueCounter 주소가 완전 전달이 된 것이 아님
 var newValueCounter = valueCounter
 print(newValueCounter.increment())
 print(newValueCounter.value)
 }

 Task {// valueCounter 주소에 접근 가능
 print(valueCounter.increment())
 print(valueCounter.value)
 } 
}</code></pre>&nbsp;네, 그래서 위와 같은 내용을 확인하시면 될 것 같고.. 강의 후반부 48강 ~ 52강 내용과 sending키워드 내용까지를 잘 보시면 질문 주셨던 내용에 대해 명확하게 이해하실 수 있으실 것 같습니다.(제가 강의 촬영 당시에는.. 컴파일러 내부에 sending키워드 관련 부분이 아마 정확하게 구현이 안되어 있어 크래시가 나지 않았는데, 정확하게 말씀드리면 해당 12강 강의 내용 중에 캡처리스트 부분에 대해 설명드리는 내용은 정확하게 컴파일러 업데이트가 되기 전 내용이라, 제대로 동작하고 있지 않은 것으로 보시면 될 것 같습니다. 즉, 지금 설명드린 내용이 Evolution문서와 정확하게 일치하게 컴파일러가 업데이트 된 내용이라고 보시면 됩니다.)&nbsp;말씀드린 강의 후반부 내용 확인해보시고도 이해가 안되시는 부분이 있으시면 다시 질문주세요 !&nbsp;감사합니다. :)

Task 클로저 내 `non-Sendable` 값 타입 접근 시, 캡처 리스트가 정의된 Task 순서에 따른 컴파일러 에러 차이

네, sujinnaljin 님 첫번째 질문) 아, 네네 단순 예시라서 제가 꼼꼼하게 작성하지는 않았었네요! 말씀하신대로 정확하게 작성하신다면.. 아래와 같은 형태로 작성하시는 것이 당연히 맞습니다. (삭제도 딕셔너리에 접근하는 것이니까요.)<pre><code class="language-swift">func clearAll() {
 lock.lock()
 cache.removeAll()
 lock.unlock()
}</code></pre>&nbsp;두번째 질문)아 네, NSCache 자체는 내부적으로 일단 Thread-safe하기 때문에 @unchecked Sendable 만 사용하셔도 됩니다. (아래와 같은 처리를 안해도 된다는 것이겠죠.)<pre><code class="language-swift">func setValue(_ value: Value, for key: Key) {
 semaphore.wait()
 cache[key] = value
 semaphore.signal()
}</code></pre><pre><code class="language-swift">func setValue(_ value: Value, for key: Key) {
 lock.lock()
 cache[key] = value
 lock.unlock()
}</code></pre>&nbsp;그리고.. 일단 공식문서에 Thread-safe하다고 나와있으니, (저라면) 아래처럼 그냥 직접적으로 사용할 것 같고..<pre><code class="language-swift">func setValue(_ value: Value, for key: Key) {
 cache[key] = value
}</code></pre> 만약에 그 전에 (1) NSCache를 사용해본 적이 없거나, (2) 공식문서를 미리 확인하지 않았다는 가정을 해보면, 당연히 @unchecked Sendable + 안전하게 위(semaphore or lock)와 같은 처리를 사용할 것 같습니다. (물론 예를 들어, 위와 같은 메서드 로직에서 NSCache만 사용하는 것이 아니라, 다른 딕셔너리 등도 속성으로 같이 처리해주는 등이 있다면, 아무리 NSCache를 사용한다더라도, semaphore 나 lock 을 사용해야겠지만요.) 답변이 되셨으면 좋겠습니다. :)&nbsp;&nbsp;감사합니다...!

18강 NSCache 예시 질문

네, sujinnaljin 님&nbsp;강의 내용에서도 말씀드리고 있지만.. 크게 중요한 내용은 아닌 것 같아서.. ^^; 제가 굳이 다시 찾아보지는 않았었네요.&nbsp;Task 의 default 우선순위가 medium 인 것이 맞습니다. (제가 알기로는 Swift버전이 업데이트 되면서 중간에 바뀐 것 같네요. 초반에 자료를 만들기 시작할때는 utility 였던 것으로 기억하고 있어서요.) &nbsp;불편을 드렸다면 죄송합니다. &nbsp;강의는.. 전반적인 내용 큰틀을 이해하시는 데는 도움이 되실 수 있으나, 아주 디테일한 내용에서는 직접 공식문서 등을 통해서 찾아보신 내용이 당연히 우선시 되리라고 생각됩니다.&nbsp;감사합니다 :)

Task 의 default 우선순위 문의 (utility vs medium)

아 네, 큰 의미가 있는 것은 아니고 그냥 단순하게 두가지 의미 때문에 취소선으로 표시해 놓은 것이기는 한데, "메타데이터"라는 것에는 (1) 첫번째로는 현재 실행 중인 액터가 있을 수도 있고 아닐 수도 있어서 취소선으로 표시해놓은 것 입니다. 즉, 구조적 동시성이 액터 내부에서 실행하는 경우 - 액터 상속하게 되고, 액터 내부가 아닌 곳에서 실행하는 경우 - 상속할 액터가 없어서... 상속할 액터가 있는 경우/없는 경우 때문에 그렇습니다. (2) (다른 측면에서는) 구조적 동시성 자체가 병렬처리를 목적으로 하는 것이라.. 부모 작업의 경우는 액터에서 실행될 수 있지만, 하위(자식) 작업들은 병렬로 처리되어 (액터와 상관없이) 실행되기 때문에 그런 의미에서 살짝(?) 표시를 해둔 것이긴 합니다.&nbsp;감사합니다. :)

18강 자식 작업의 메타데이터 상속 관련 강의 자료 문의

아 네네, sujinnaljin 님.강의 내용이 잘못된 것 같네요! 공식 문서 내용을 저도 다시 확인해보니, 해당 부분에 대한 내용을 제가 자세하게 체크하지 못한 부분이 있네요! 말씀하신 내용이 맞습니다 ^^; (아마 저도 초반 학습 할 때의 내용에 대해 추후에 자세하게 살펴보진 않아서 더블 체크를 못했던 부분이네요.)&nbsp;강의 내용, 교재 내용도 수정해 놓아야 겠네요! 알려주셔서 감사합니다 :)

withCheckedContinuation 에서 resume 호출의 안정성 보장 질문

아, 네 맞네요ㅠㅠ 오타가 있었네요!&nbsp;네 A코드의 형태는 잘못되었고, (아래와 같은) 사용하신 B의 형태가 정확히 맞습니다. (자료도 수정해 놓겠습니다.)<pre><code class="language-swift"> /// 구조적 동시성 작업의 생성 (하위 작업의 생성)
 async let image1 = fetchImage(num: 1)
 async let image2 = fetchImage(num: 2)</code></pre> 질문에 정확한 답변을 드리고 싶지만..제 생각에는 잘못된 코드를 분석한다는게 크게 의미가 없을 것 같습니다..ㅠㅠ 어차피 A코드와 같은 형태로 사용하는 것이 아니라, 잘못된 코드일뿐인 것이죠. (잘못된 코드인데, 자체적으로 컴파일러가 오류를 잡아주지 않는 것일뿐이라고 보시면 될 것 같습니다.)&nbsp;그냥 단순히, 진짜 제 개인적인 뇌피셜로는 내부적으로 B코드와 완전히 동일하게 동작할 것 같긴합니다. <pre><code class="language-swift"> /// 구조적 동시성 작업의 생성 (하위 작업의 생성)
 async let image1 = try await fetchImage(num: 1)
 async let image2 = try await fetchImage(num: 2)</code></pre>왜냐면, 위와 같은 코드에서 컴파일 될때, 왼쪽의 코드인.. async let의 코드를 먼저 컴파일 시킬 것이기 때문에, 실제 async let image1 코드에서 일단 비동기 함수를 호출 시키고 다음 줄의 코드로 넘어가는 동작으로 async let image2를 컴파일 시킬 것 같습니다.(다만, 측정하신 시간이 다르게 나온 이유는 정말 단순하게 플레이그라운드 실행 환경의 문제이지 않을까 싶습니다. 수백번의 실험을 해보면 얼추 비슷하게 나올 것 같습니다.)&nbsp;코드 내용을 주의 깊게 봐주셔서 감사합니다. :)

allen

投稿