skyplace

動的アクター分離チェックの調査方法

2024-11-11T00:00:00+00:00

Swift6の動的アクター分離チェックによってクラッシュした場合、正しいコードに飛べず、原因が分かりにくい場合があります。
その場合の調査方法を紹介します。

まず、_dispatch_assert_queue_failが動的アクター分離チェックによるクラッシュです。
フレームを選択してもコードにジャンプしませんが、lldbから該当のコードを確認することができます。

(lldb) bt
* thread #11, queue = 'com.apple.usernotifications.UNUserNotificationServiceConnection.call-out', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x000000010d6076f5 libdispatch.dylib`_dispatch_assert_queue_fail + 102
    frame #1: 0x000000010d60768f libdispatch.dylib`dispatch_assert_queue + 159
    frame #2: 0x00007ffc124d6271 libswift_Concurrency.dylib`swift_task_isCurrentExecutorImpl(swift::SerialExecutorRef) + 385
    frame #3: 0x000000010d155120 Sample.debug.dylib`closure #1 in ViewController.viewDidLoad(isAuthorized=false, _1=nil) at ViewController.swift:0
    frame #4: 0x000000010d15523f Sample.debug.dylib`thunk for @escaping @callee_guaranteed (@unowned Bool, @guaranteed Error?) -> () at <compiler-generated>:0
    frame #5: 0x000000010d604b3d libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #6: 0x000000010d605ec6 libdispatch.dylib`_dispatch_client_callout + 8
    frame #7: 0x000000010d60ddcf libdispatch.dylib`_dispatch_lane_serial_drain + 1078
    frame #8: 0x000000010d60eb50 libdispatch.dylib`_dispatch_lane_invoke + 448
    frame #9: 0x000000010d61bc76 libdispatch.dylib`_dispatch_root_queue_drain_deferred_wlh + 318
    frame #10: 0x000000010d61b19d libdispatch.dylib`_dispatch_workloop_worker_thread + 837
    frame #11: 0x000000010d1d9b84 libsystem_pthread.dylib`_pthread_wqthread + 327
    frame #12: 0x000000010d1d8acf libsystem_pthread.dylib`start_wqthread + 15
(lldb) f 3
frame #3: 0x000000010d155120 Sample.debug.dylib`closure #1 in ViewController.viewDidLoad(isAuthorized=false, _1=nil) at ViewController.swift:0
   19  	    override func viewDidLoad() {
   20  	        super.viewDidLoad()
   21
-> 22  	        UNUserNotificationCenter.current().requestAuthorization { isAuthorized, _ in
   23  	            self.isAuthorized = isAuthorized
   24  	        }
   25  	    }
Note: this address is compiler-generated code in function closure #1 (Swift.Bool, Swift.Optional<Swift.Error>) -> () in Sample.ViewController.viewDidLoad() -> () that has no source code associated with it.

この記事で用いたコードはこちらから確認することができます

[Swift6] アクター分離境界 (Actor isolation boundary) を考慮したcallback

2024-11-10T00:00:00+00:00

この記事では、同期関数 (no-async) のcallbackにおけるアクター分離境界（以降、アクター境界）の考え方について解説します。

この記事は上記に続く3つ目の記事です。以前の記事の内容を前提にしている場合があります。

同期関数のcallbackとは

async関数以前は、非同期に実行する場合callbackで結果を受け取る必要がありました。
例えば、以下のようなコードです。このような関数はSwift6によってどのように変わるでしょうか。

func fetch(request: Request, completion: @escaping (Result<Response, Swift.Error>) -> Void) {
    URLSession.shared.dataTask(with: request.makeRequest()) { data, urlResponse, error in
        // 省略
        completion(result)
    }.resume()
}

異なるアクター上でcallbackが呼び出される場合

まずは、callbackが異なるアクター上で呼び出されるケースを考えます。

この場合、callbackはアクター境界を越えるので、Sendableにする必要があります。
しかし、それだけでは足りません。多くの場合はcallbackで結果を受け取り、元のアクター上に持っていく必要があります。

これを考慮すると以下のコードになります。

// ResultがSendableの場合 (= ResponseがSendableの場合) はsendingは不要です
func fetch(request: Request, completion: @escaping @Sendable (sending Result<Response, Swift.Error>) -> Void) {
    URLSession.shared.dataTask(with: request.makeRequest()) { data, urlResponse, error in
        // 省略
        completion(result)
    }.resume()
}

// On MainActor
Service().fetch(request: Request()) { [weak self] result in
    Task { @MainActor in
        if case let .success(response) = result {
            self?.res = response
        }
    }
}

呼び出し側が煩雑になりますが、このやり方は呼び出し側で、スレッド呼び出しを必要最小限に制御することができるというメリットがあります。
その為、繰り返し高い頻度で呼び出され、オーバヘッドを極力減らしたい場合に検討するのが良いでしょう。

同じアクター上でcallbackを呼び出す場合

では、どうやって呼び出し側の煩雑さを軽減するかと言うと、callbackの呼び出しを同じアクター上にすることで、これが実現できます。

1. 呼び出し側でActorを指定する

@isolated(any) Function TypesによってClosureをどのアクター上で実行するべきかを引き継げるようになりました。
これを用いると、以下のコードになります。

func fetch(request: Request, completion: @escaping @isolated(any) (Result<Response, Swift.Error>) -> Void) {
    nonisolated(unsafe) let completion = completion

    URLSession.shared.dataTask(with: request.makeRequest()) { data, urlResponse, error in
        Task {
            // 省略
            await completion(result)
        }
    }.resume()
}

// On MainActor
Service().fetch(request: Request()) { [weak self] result in
    // On MainActor
    if case let .success(response) = result {
        self?.res = response
    }
}

この方法だと、@isolated(any)は@MainActorと同様に暗黙のSendableとして扱うべきにも関わらず、Swift6.0時点では扱われていない為、nonisolated(unsafe)を使う必要があります。
Closure isolation controlというプロポーザルは出ているので、これが実装されればnonisolated(unsafe)を使わない書き方にできる可能性があります。この方法はやや時期尚早と言えます。

2. GlobalActorを用いる

GlobalActorを使用している場合は、これを使うことでより簡略化することもできます。

func fetch(request: Request, completion: @escaping @MainActor (Result<Response, Swift.Error>) -> Void) {
    URLSession.shared.dataTask(with: request.makeRequest()) { data, urlResponse, error in
        Task { @MainActor in
            // 省略
            await completion(result)
        }
    }.resume()
}

// On MainActor
Service().fetch(request: Request()) { [weak self] result in
    // On MainActor
    if case let .success(response) = result {
        self?.res = response
    }
}

呼び出し側・実装側が共に同じGlobalActorの場合は、適切な選択肢と言えます。

3. asyncにする

お気づきのことと思いますが、「同じアクター上でcallbackを呼び出す」というのはasync関数でやっていることと同じです。その為、async関数に変更するという選択肢もあります。

従来実装(`non-Sendable`)の挙動

関連して、従来実装の場合はどのような挙動になるか解説します。

例えば、UIViewController.present(_:animated:completion:)などのcallbackは@Sendableもアクターの指定もありません。
これは、何故動作しているのでしょうか？

動的アクター分離チェック

挙動が分かりやすい、UNUserNotificationCenter.requestAuthorization(options:completionHandler:)を例に取ります。

override func viewDidLoad() {
    super.viewDidLoad()

    // On MainActor
    UNUserNotificationCenter.current().requestAuthorization { isAuthorized, _ in
        // On OtherActor
        self.isAuthorized = isAuthorized
    }
}

これはコンパイルは通りますが、アクター境界を越えてcallbackが実行される為、実行時にクラッシュします。
これは、Unmarked Sendable Closuresにあるように、動的アクター分離チェックが動作している為であり、以下のように変更することで正しく動作するようになります。

UNUserNotificationCenter.current().requestAuthorization { @Sendable isAuthorized, _ in
    Task { @MainActor in
        self.isAuthorized = isAuthorized
    }
}

`non-Sendable`で良い場合

ではUIViewController.present(_:animated:completion:)が何故問題ないのかと言うと、関数呼び出しとcompletionは必ずMainActorで実行される為、アクター境界を越えることがない為です。
言い換えると、アクター境界を跨がない場合は従来通りの定義で良いということでもあります。
しかし、多くの場合Swift6下ではコンパイルエラーになる為、何らかの回避方法が必要になります。

@MainActor class MainActorService {
    func fetch(request: Request, completion: @escaping (Result<Response, Swift.Error>) -> Void) {
        URLSession.shared.dataTask(with: request.makeRequest()) { data, urlResponse, error in
            Task { @MainActor in
                // 省略

                // CompileError: Capture of 'completion' with non-sendable type '(Result<Response, any Error>) -> Void' in a `@Sendable` closure
                completion(result)
            }
        }.resume()
    }
}

この記事のコードはこちらから確認することができます

[Swift6] アクター分離境界 (Actor isolation boundary) を考慮したasync関数の定義パターン

2024-11-09T00:00:00+00:00

アクター分離境界（以降、アクター境界とする）を意識しなければならない箇所はいくつかありますが、その際たる例はasync関数です。
この記事ではasync関数におけるアクター境界の考え方について解説します。

前回の記事でアクター境界について解説をしている為、必要に応じて参照してください。

前提

前提として、Sendableであれば常にアクター境界を越えることができる為、アクター境界を意識する必要はありません。その為、この記事ではRequestとResponseというnon-Sendableな型を使って考えます。

class Request {}

@available(*, unavailable)
extension Request: Sendable {}

class Response {}

@available(*, unavailable)
extension Response: Sendable {}

async関数が呼び出された時の実行スレッド

Swift6からアクターの紐付けのないasync関数の実行は、汎用Executorに割り当てられるようになりました。
その結果、実行スレッドは以下のようになります。

func fetch(_ request: Request) async throws -> Response {
  // On Thread2
  let (data, _) = try await urlSession.data(for: request.makeRequest())
  // On Thread2
  return Response(data: data)
}

Task {
  // On Thread1
  let res = try await fetch(Request())
  // On Thread1
}

よって、async関数を呼び出した際の引数と返り値がアクター境界を越える必要が出てきます。

アクターのasync関数の場合

1. sendingを用いる

では、アクターのasync関数について考えます。
この場合、最もオススメの定義はsendingを用いた以下の定義です。

func fetch(_ request: sending Request) async throws -> sending Response {}

sendingキーワードを用いることで、引数と返り値がアクター境界を越えることができるようにすることができます。
但し、引数は呼び出し側、返り値は実装側のメンバ変数に値を保持しておくことができなくなります。
その理由については、前回の記事を参照してください。

2. GlobalActorを用いる

メンバ変数として保持したい場合は、呼び出し側と同じGlobalActorを用いる必要があります。

@MainActor class Service {
  func fetch(_ request: Request) async throws -> Response {}
}

@MainActor class Controller {
  func run() {
    Task {
      self.response = try await self.service.fetch(self.request)
    }
  }
}

このようなケースであれば、そもそもアクター境界を越えることがない為、メンバ変数に保持したとしても常に同じスレッドからしかアクセスされない為、問題がありません。

アクター以外のasync関数の場合

isolationの指定をする

func fetch(_ request: Request, isolation: isolated (any Actor)? = #isolation) async throws -> Response {}

アクター以外の場合は呼び出し側からisolationを引き継ぐのがオススメです。
この方法をアクターに用いる場合はnonisolatedと扱われてしまい、関数内でのメンバ変数へのアクセスが困難になりますが、アクターでない場合はこの問題がありません。

但し、Sendableのasync関数の場合は、メンバ変数に保存する場合は異なるスレッドからアクセスされる可能性がある点には注意して実装する必要があります。
@unchecked Sendableにしている為コンパイルエラーにはなりませんが、この場合に限らず、スレッドセーフとして扱うのであれば常に意識すべき点でもあります。

let service = SendableService()

actor Actor1 {
  func run() async throws -> Response {
    // On Thread1
    return try await service.fetch(Request())
  }
}
actor Actor2 {
  func run() async throws -> Response {
    // On Thread2
    return try await service.fetch(Request())
  }
}

class SendableService: @unchecked Sendable {
  private let urlSession = URLSession.shared
  private var request: Request?
  private var response: Response?

  init() {}

  func fetch(_ request: Request, isolation: isolated (any Actor)? = #isolation) async throws -> Response {
    // On AnyThread
    self.request = request
    let (data, _) = try await self.urlSession.data(for: request.makeRequest())

    // On AnyThread
    let response = Response(data: data)
    self.response = response
    return response
  }
}

一方、non-Sendableの場合は、そもそも同じスレッドからしか呼び出されないと考えることができるので、これを考慮する必要がありません。

@MainActor class Controller1 {
  let service: NonSendableService
  init(service: NonSendableService) {
    // On MainThread
    self.service = service
  }

  func run() async throws -> Response {
    // On MainThread
    return try await service.fetch(Request())
  }
}

@MainActor class Controller2 {
  func run() {
    Task {
      // On MainThread
      let service = NonSendableService()
      let c1 = Controller1(service: service)
      let res = try await service.fetch(Request())
    }
  }
}

参考文献

[Swift6] アクター分離境界 (Actor isolation boundary) を理解する

2024-11-04T00:00:00+00:00

Swift6から本格導入された、Actor isolation boundaryについて解説します。
Swift5でもActorは導入されていましたが、Swift6がリリースされるまでの過程でいくつかの変更が入っており、それらを踏まえたものなので、Swift5のActorの説明とは異なる箇所がある点には注意してください。

また、それなりに調べた上で書いていますが、正確な情報を保証する物ではない為、必要に応じて公式ドキュメントを参照してください。この記事において参照したソースについては、末尾に記載しています。

ActorとActor isolation boundaryの基本的な考え方

ActorとExecutor

同時実行性を制御する概念として、Actorが導入されました。
SwiftにおけるActorは、従来のオブジェクト指向にアクターモデルの概念を取り入れた物で、「同時実行性についての指定をClassに加えた物」と捉えて概ね問題ないでしょう。

Actorは1つのSerialExecutorを（多くの場合は暗黙的に）指定します。
このSerialExecutorはDispatchSerialQueueのようなもので、キューイングされたJobを順番に処理する役割を担います。（便宜上、SerialExecutorのことを指して以降はExecutorと書きます）

例えば、上記の図のようにActor AとActor Bが同じExecutorを指定した場合、Actor AとActor Bのメソッドは同時には1つしか実行されないことが保証されます。
逆に、別のExecutor βを指定したActor CはActor Aのメソッドと同時に実行される可能性があることを意味します。

Executorによる排他制御で説明しましたが、当然Actor Aのメソッド同士も同時に実行されません。
多くの場合は、Executorを意識することはないのでActorのメソッドは同時に実行されることがないと捉えて問題ありません。
これによって、並列プログラミングによる排他制御を行おうというのが基本的な考え方です。

Actor isolation boundaryとSendable

先ほどの例においてActor AとActor Cは別のExecutorで実行されるとしました。
では、Actor AからActor Cの以下のようなメソッドを呼び出す場合はどうなるでしょうか。

func fetch(request: Request) async throws -> Response

この時、RequestとResponseはActor AとActor C上の両方で扱われることになり、同じデータ領域に同時に書き込みが行われる可能性があります。
このように複数のActorを跨ぐことを「アクター分離境界を越える (across actor isolation boundaries)」と言います。（Actor boundary, Isolation boundaryなど表記のブレがありますが、以降はアクター境界と書きます）

値コピーされる構造体や、スレッドセーフなクラスを「アクター境界を超えられる」とすることで、Actor間のやり取りが安全であることが分かるようになります。この、「アクター境界」を超えられる値というのが、Sendableです。

Region based isolation

しかし、アクター境界を越える為には、必ずSendable（＝スレッドセーフ）でなければならないのでしょうか？
別の形で異なるアクター上で同時に扱われないことが保証されるのであれば、値自体がスレッドセーフでなくても良いはずです。そこで導入されたのが「Region based isolation」です。

/** on Actor C */
func fetch(request: sending Request) async throws -> sending Response {
  let (data, _) = try await urlSession.data(for: request)
  return try decode(data, to: Response.self) // Responseは以降、Actor Cでアクセスされない
}

/** on Actor A */
let req = Request()
self.res = try await c.fetch(request: req) // Requestは以降、Actor Aでアクセスされない

このようなコードがあった場合、RequestはActor AからActor Cに、ResponseはActor CからActor Aにアクセス権を移譲した形になり、安全なコードであると言えます。
このアクセス権の移譲の必要性を判別できるようにする為に、sendingキーワードが導入されました。sendingキーワードがある引数に渡したインスタンス、もしくはsendingキーワードのある返り値にしたインスタンスは、メンバ変数などに保持しておくことができなくなります。

同時実行制御の為の1単位としてのActor

ここまでで基本的なActorの概念を説明しましたが、実際にはもう少し複雑になります。
前言を撤回するようですが、実際はActorはオブジェクト指向におけるClassと同じレイヤーの存在ではありません。時にはClassの一部がActor上で呼び出されず、また、別のClassがActor上で呼び出されることもあります。

つまり、SwiftにおけるActorは、同時実行制御の為の一つの単位でしかなく、クラス・関数・変数を横断的にグループ化したものです。
ここからは、そのグループ化の仕方と、その意義を解説します。

GlobalActor

iOSアプリ開発において、最も一般的な分離はメインスレッドでの実行を指定することです。
UIViewやUIViewControllerなどの、UIに関する操作は今までもメインスレッドで行う必要がありました。
これらについて都度Actorを定義する必要性はないので、GlobalActorという共通で利用できるActorが定義され、その1つとしてMainActorも定義されました。

@MainActor class Service {}
@MainActor var value: Int
@MainActor func someMethod() {}

このように、既存の変数・関数・クラスに対してGlobalActorを紐づけることが可能となります。
これの便利なところは、同じGlobalActor上であればアクター境界を超えないという点にあります。これによってSendableを意識せずとも、クラス間のやり取りができるようになります。

nonisolated

iOSアプリ開発で広く使われてきたデザインパターンに、Delegateパターンがあります。
例えば、以下のようなDelegateがあった場合に、果たしてこれが実行されるのはどのActorでしょうか？

@MainActor
protocol Delegate {
  func reload()
}

actor A: Delegate {
  func someMethodX() {
    reload() // on Actor A?
  }
}
extension A: Delegate {
  func reload() {} // on Actor A?
}

actor B {
  func someMethodY() {
    reload() // on Actor B?
  }
}
extension B: Delegate {
  func reload() {} // on Actor B?
}

protocolを実装する場合、protocolで定義されたActorと実装側のActor定義があり、これが一致しない場合に不都合が生じます。
このようなケースに使われるのがnonisolated（非分離）です。Swift6では、これらが一致しない場合に非分離（= クラスで指定されたActor上では実行されない）とする必要があります。

extension A: Delegate {
  nonisolated func reload() {}
}

この場合は、Delegateが@MainActorとしているので、reloadはActor A上ではなく、MainActor上で実行されることになります。
但し、nonisolatedなメソッドからメンバ変数に直接アクセスしようとすると、アクター境界を越えることになるので、コンパイルエラーになります。

actor A {
  var value: Int
}
extension A: Delegate {
  nonisolated func reload() {
    self.value = 1 // Actor boundary error
  }
}

isolated

逆に特定のメソッドや変数を指定したActor上に分離することもできます。それがisolated（分離）です。

func deposit(amount: Double, to account: isolated BankAccount) {
  // on Actor(BankAccount)
}

これをうまく用いることによって、不必要な非同期処理を削減し、パフォーマンスの向上を図ることができます。
また、アクター境界を越えることができない場合に、この方法でアクター境界を超えない形に実装することもできます。

アクター境界について解説しました。近日中に実践的なSwift6対応についての記事も投稿したいと思います。（多分……）

参考文献

Combineの実行タイミングについて理解する

2024-10-31T00:00:00+00:00

delegateで自分で実装した場合は、実行の割り込みタイミングは自明だが、Combineについては今まで雰囲気で使っていたので、理解を深めつつ備忘録として調査内容を残す。

環境

Swift 6.0
Xcode 16.0

Scheduler

何も指定していない時、SchedulerはImmediateSchedulerと同様の動作をする（つまり、割り込み実行）
DispatchQueueを指定した場合はDispatchQueue.asyncのような動作をする

実行スレッド

Receive Schedulerによって決まる。

receive(on:)で指定されたスレッドで非同期に実行される
receive(on:)で指定しない場合、もしくはImmediateSchedulerに準ずるSchedulerを指定した場合は、send中に同期的に実行される（割り込み実行）

つまり、MainThread以外でPublish可能かつMainThreadでcallbackを実行したい場合は、receive(on: DispatchQueue.main)を指定する必要がある

Combine.Published

@Published varで定義するとPublisherを利用することができる。
このPublisherは以下のように動作する。

Subscriber接続時に即座にpublishされる
値更新のwillSet時にpublishされる

つまり、Receive ScedulerがImmediateSchedulerの場合にreceive時にプロパティを参照すると前の値が参照される。
特にreceive時にメソッドを呼び出す場合、Publishされてきた値を使用しなければならない点に注意する必要がある。
Schedulerを指定することで常に最新の値を参照することも可能。

排他制御

異なるスレッドから同時にpublishされた場合でも、その回数分のpublishが実行される

ImmediateSchedulerの場合

let data = Data()
cancellables = [
    data.$value1.sink { value1 in
        print("--- receive: \(value1)")
        usleep(2000)
        print("--- receive = \(value1), current = \(data.value1)")
    },
]
(1...5).forEach { value in
    DispatchQueue.global().async {
        usleep(useconds_t(value * 1000))
        print("enqueue: \(value)")
        data.value1 = value
        print("end: \(value), current = \(data.value1)")
    }
}

--- receive: 0
--- receive = 0, current = 0
enqueue: 1
--- receive: 1
enqueue: 2
--- receive = 1, current = 0
enqueue: 3
end: 1, current = 1
--- receive: 2
enqueue: 4
enqueue: 5
--- receive = 2, current = 1
end: 2, current = 2
--- receive: 3
--- receive = 3, current = 2
end: 3, current = 3
--- receive: 5
--- receive = 5, current = 3
end: 5, current = 5
--- receive: 4
--- receive = 4, current = 5
end: 4, current = 4

このようにシーケンシャルに実行されるが、やや直感に反する挙動になる

値の書き込み時にlockが取られ、callbackの処理が割り込み実行される
複数の書込みが待機している場合、待機した順番とは異なる順番で処理される可能性がある

SerialQueueの場合

let data = Data()
cancellables = [
    data.$value1.receive(on: queue).sink { value1 in
        usleep(1000)
        print("receive = \(value1), current = \(data.value1)")
    },
]
let lock = NSLock()
(1...5).forEach { value in
    DispatchQueue.global().async {
        usleep(useconds_t(Int.random(in: 0...100)))
        lock.withLock {
            print("enqueue: \(value)")
            data.value1 = value
        }
    }
}

enqueue: 3
enqueue: 5
enqueue: 1
enqueue: 2
enqueue: 4
receive = 0, current = 4
receive = 3, current = 4
receive = 5, current = 4
receive = 1, current = 4
receive = 2, current = 4
receive = 4, current = 4

こちらはenqueueした順番に確実に処理することができる。

Upstreamへのメッセージ送信のSchedulerを指定することができる.
Upstreamへのメッセージの代表的な物に、subscribeリクエストがある

@MainActor func execute4() async {
    let data = Data()
    cancellables = [
        data.$value1.subscribe(on: DispatchQueue.main).sink { value1 in
            print("argument = \(value1), current = \(data.value1), isMainThread = \(Thread.isMainThread)")
        },
    ]

    for num in 1...5 {
        data.value1 = num
    }
    try? await Task.sleep(for: .seconds(0.1))
    for num in 6...10 {
        data.value1 = num
    }
}

argument = 5, current = 5, isMainThread = true
argument = 6, current = 5, isMainThread = true
argument = 7, current = 6, isMainThread = true
argument = 8, current = 7, isMainThread = true
argument = 9, current = 8, isMainThread = true
argument = 10, current = 9, isMainThread = true

このように、subscribeを非同期にすることでsubscribe開始を遅延させることができる。
他にも特殊な使い方ができると思われるが、直感に反する挙動になりがちなので注意が必要かもしれない。

タイミング制御

様々な制御があるが、代表的なユースケースとして、複数のプロパティに対して全ての書込みが完了してから纏めて実行するという物がある。
これはdebounce(for:scheduler:)を使うことで制御できる。

let data = Data()
cancellables = [
    Publishers.CombineLatest(data.$value1, data.$value2)
        .debounce(for: .seconds(0), scheduler: DispatchQueue.main)
        .sink { value1, value2 in
            print("receive: value1 = \(value1), value2 = \(value2) / current: value1 = \(data.value1), value2 = \(data.value2)")
        }
]

Task { @MainActor in
    try? await Task.sleep(for: .seconds(0.1))
    (11...20).forEach { data.value1 = $0 }
    (21...30).forEach { data.value2 = $0 }
}

receive: value1 = 0, value2 = 0 / current: value1 = 0, value2 = 0
receive: value1 = 20, value2 = 30 / current: value1 = 20, value2 = 30

上記はメインスレッドで実行している為、全てが終わってから処理される。
別スレッドで書込みをしている場合は、全て完了する前に実行されるが、それでもある程度は纏めて実行される。万が一パフォーマンスが気になる場合は、時間を調整すると良い。

この記事中のコードはGitHub上で確認できる。

「きみの色」の解釈について

2024-09-03T00:00:00+00:00

山田尚子監督の「きみの色」を観てきた。
ストーリーについて自分なりの解釈を纏めようと思う。本編のネタバレを含むので、未視聴の場合は気をつけて欲しい。

トツ子が見る色とは？

トツ子はファンタジックな能力を持っていない

話の随所で登場する日暮トツ子の「人の色が見える」という設定から考える。
これをファンタジックな能力（つまり、トツ子は実際に視界にその色を捉えている）と解釈することも可能だが、他の人間が見ている情景も見えていることから、これは比喩的な表現だと考えるのが妥当だと思う。

多くの人は声を聞くだけで、その人が「怒っているか」「悲しんでいるのか」をある程度判別することができると思う。その延長で、トツ子は行動や雰囲気といったものも含めて、その人の性質や感情を言語化できない形、つまり色として認識しているのではないだろうか。

これは、恋を知らないから言語化できないが、その雰囲気を敏感に感じ取れる。そういった若年層の性質をうまく演出に設定だと思う。

それぞれのキャラの色の意味

クリスマスのシーンで作永きみからピンク色を感じたなど、その時の感情によって変わるものではあるが、本作では各キャラクターの性質を色という形で設定している。
では、それぞれに設定される色にはどのような意味があるのだろうか。これは、色彩心理と大きく紐づいていると考えられる。

日暮トツ子（赤色）：明るい、リーダーシップ、行動的
作永きみ（青色）：冷静沈着、知性的、クール、寂しい
影平ルイ（緑色）：慈愛、安心、落ち着いている

それぞれが作成する楽曲にもこれらの性質は色濃く現れており、きみの曲に対し、ルイは寂しそうだったからと包み込むようなアレンジを加えるシーンは、青と緑を象徴するシーンだった。

そして、作中で出てくるピンク色は当然、恋だろう。トツ子が子供の頃に、私もピンクになりたいと言うのは「恋をしたい」（恋というものを知らないけど）ということなのだと思う。何とも、女の子らしいことである。

悩みと成長

トツ子の場合

本作は悩みを抱えた少年少女がバンドを通して成長する物語である。では、トツ子は何に悩み、そして成長したのだろうか。

冒頭に他の人との違い（＝色が見えること）についての説明があるのでミスリーディングになっているように思うが、トツ子の成長は「自分の色が分かる」ことで描かれるので、色が見えることが悩みではないと考えられる。
もし、色が見えること自体が悩みなのだったとすると、最後には色が見えなくなる（気にならなくなる）というのがよくあるストーリー展開である。（同監督の「聲の形」はその類型である）

では、トツ子の悩みが何かというと、教会での祈りのシーンにヒントがある。

神よ、変えることのできないものを静穏に受け入れる力を与えてください。
変えるべきものを変える勇気を、
そして、変えられないものと変えるべきものを区別する賢さを与えてください。

トツ子が教会で祈るシーンで、ニーバーの祈りが引用され、今自分が欲しいのは「変えることのできないものを静穏に受け入れる力」であると述べる。

タイミング的に他の解釈もありそうだが、トツ子は自己という「変えることのできないもの」について受け入れることができていないのだと思う。だからこそ、他人の色（＝性格・性質）に憧れ、自分の色（＝自分の良いところ）を見ることができていない。

バンドシーンにおいて、前2曲では観客の心を掴めていなかったにも関わらず、トツ子が作曲した「水金地火木〜」が始まるや否や体育館に人が集まってくる。
これは、トツ子が持つ人を明るくさせる力が色濃く出たものだろう。トツ子は作中を通して、自分の良いところを受け入れ、赤色の特徴があることに気づくことができたのだ。

きみとルイの場合

きみは祖母に学校を中退したことを打ち明けられずにいる。そして、ルイは母親の期待に反して音楽をやりたいというのを隠している。
これらは作中で分かりやすく描かれ、2人が同時に打ち明けてライブに来て欲しいと言うシーンは本作の重要なシーンになっている。

では何故2人は打ち明けることができなかったのだろうか。それは、親（母親・祖母）の期待する人物像と相反する自己との間に葛藤があったからだろう。
そう捉えると、この3人は皆、自己の形成において悩みを持ち、他の2人との交流を経て、自分を認めることができるようになり、前へ進めるようになったのだと思う。

現代における宗教の役割

そう考えると、本作では一貫して自己形成について描いていることになるが、そうするとミッションスクールが舞台となった理由も見えてくる。

日本において宗教は忌避されがちであるが、実際のところ神道・儒教・仏教といった教えが価値観の中に深く根付いている。例えば、年上を敬うという価値観は儒教から来ていると思われるし、物を大切にするのは神道から来ているように思う。多くの日本人は無宗教などと言いながら、明文的に教わっていないが故に様々な宗教が入り混じった価値観を有している。
科学の発展などによって宗教の意義は昔と比べると失われつつあるが、それでも「生きる目的」「自分の在り方」といった自己形成面での意義は大きいのではないだろうか。

作中では、トツ子は学校の中でも珍しい教会によくいる生徒として描かれ、3人の中では最も自己形成ができていると言える。
そんなトツ子に影響される形で2人は自己が整っていく。このように解釈すると、とてもシンプルな物語となり、点と点が繋がっていくのではないだろうか。

映画本編以外の情報をあまり仕入れていないので、筋違いのことを書いているかもしれないが、内容の理解の一助になれば幸いである。

SwiftUIでPreviewの内容が実体と異なる場合がある話

2024-08-25T00:00:00+00:00

SwiftUIにおいて、そのView(A)のPreviewでは正しいのに、Aを使ったView(B)のPreviewでは正しくないという現象に遭遇した。
まずは結論から。

結論

同名のViewがあった場合に、Previewの場所によって異なるViewになるので、同名の構造体・クラスは明確に指定するべき。

発生条件と再現方法

再現コードを公開しているので、コード全体を見たい場合はこちらを参照してください。

public extension Form {
    struct Group<Content: View>: View {
        // 省略
    }
}

public extension Form {
    struct Announce<Content: View>: View {
        private let content: Content

        public init(@ViewBuilder content: () -> Content) {
            self.content = content()
        }

        public var body: some View {
            Group { // このGroupが`Form.Group`になるか`SwiftUI.Group`になるかが変わる
                content
            }
        }
    }
}

#Preview {
    Form.Announce {
        Text("Does it use SwiftUI.Group?")
    }
}

ここでForm.Announce.body内で使用されているGroupは近いところに定義されている物が選ばれる為、Form.Groupとなるはずだった。
しかし、このPreviewを確認してみると、SwiftUI.Groupが使用されている。

class ViewController: UIHostingController<AnyView> {
    init() {
        super.init(rootView: AnyView(Form.Announce {
            Text("Does it use SwiftUI.Group?")
        }))
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

次に、AnyViewでラップしてはいるが、同様の内容を実際に表示してみる。
すると、以下のような画面になり、先ほどとは見た目が異なる結果となる。これは、Form.Announce.body内で使用されているGroupがForm.Groupとして解決された結果だ。

色々と試した結果、Previewは常にSwiftUIのViewを優先するということもないようで、何か他にも条件がありそうではある。
という訳で、同名の構造体・クラスには気をつけましょうという話でした。

iOS17 Simulatorだとin-app purchaseのテストでSKError.Code.unknownが返る問題の対策

2024-01-27T00:00:00+00:00

SKTestSessionを用いたテストが、Xcode15になってからiOS17 Simulatorでのみテストが通らなくなった場合の対応方法を紹介する。

iOS17では、SKTestSession.failTransactionsEnabledがdeprecatedになった。これに伴い、ここら辺の挙動がおかしくなっている。
もしデフォルト値のfalseから返る必要がないにも関わらず設定している箇所がある場合はそのコードを削除する必要がある。（unavailableを使わずに単に削除しても良いと思う）

// before
session.failTransactionsEnabled = false

// after
if #unavailable(iOS 17.0, *) {
  session.failTransactionsEnabled = false
}

これは、iOS17環境下では代入を行うと強制的にtrueになるという謎の問題があるからである。

(lldb) po session.failTransactionsEnabled
false
(lldb) po session.failTransactionsEnabled = false
0 elements
(lldb) po session.failTransactionsEnabled
true

trueに設定したい場合は正しく動作するように見えるが、iOS17以降はSKTestSession.setSimulatedError(_:forAPI:)に移行した方が良さそうだ。

iOSアプリにビルドハッシュを組み込む方法

2024-01-19T00:00:00+00:00

iOSアプリでビルドハッシュ (git hash)を含めるやり方はいくつかありますが、個人的に良いと思った「xcconfigとPre-actionsを用いた」方法を紹介します。

xcconfigの設定

Project > 該当するProject > Infoタブ > Configurationsセクションで、ベースになるConfigurationファイル (xcconfig)を指定することができます。

ビルドハッシュを含めたいConfigurationに対し、それぞれのファイル内で以下の行を追加します。
version.xcconfigは次のPre-actionsで生成するファイルです。

#include? "version.xcconfig"

Pre-actionsの設定

Scheme設定内、Build > Pre-actions

Shell: /bin/sh (デフォルト)
Provide build settings from: アプリケーションを指定

if which git > /dev/null; then
  echo "BUILD_HASH=$(git -C $PROJECT_DIR rev-parse --short HEAD)" > ${PROJECT_DIR}/configs/version.xcconfig
fi

出力先にxcconfigのパスは、上記のxcconfigのincludeで読み込めるパスにする必要があります。

Envをアプリ内から読めるようにする設定

info.plistに以下のように項目を追加すると、ビルド時にvalueとして環境変数が設定されます。

<key>BuildHash</key>
<string>$(BUILD_HASH)</string>

コード上では下記のようにすると利用することができます。

Bundle.main.object(forInfoDictionaryKey: "BuildHash") as? String

_UIResponderForwarderWantsForwardingFromResponderのクラッシュへの対応方法

2023-05-17T00:00:00+00:00

iOS16になってから_UIResponderForwarderWantsForwardingFromResponderでクラッシュするケースが散見されるようになりました。
一例を上げると以下のようなクラッシュログのようなものが該当します。

Thread 0 name:
Thread 0 Crashed:
 libsystem_kernel.dylib        	0x00000001c9d71574 __terminate_with_payload + 8
 libsystem_kernel.dylib        	0x00000001c9d92c34 abort_with_payload_wrapper_internal + 136 (terminate_with_reason.c:106)
 libsystem_kernel.dylib        	0x00000001c9d92c48 abort_with_payload + 16 (terminate_with_reason.c:124)
 libsystem_c.dylib             	0x000000019258ac14 _os_crash_msg + 116 (assumes.c:285)
 UIKitCore                     	0x000000018d1d3850 _UIResponderForwarderWantsForwardingFromResponder + 1256 (UITouch.m:240)
 UIKitCore                     	0x000000018d0ebcbc __forwardTouchMethod_block_invoke + 44 (UIResponder.m:2171)
 CoreFoundation                	0x000000018b053328 __NSSET_IS_CALLING_OUT_TO_A_BLOCK__ + 24 (NSSetHelpers.m:10)
 CoreFoundation                	0x000000018b0d28f8 -[__NSSetM enumerateObjectsWithOptions:usingBlock:] + 200 (NSSetM_Common.h:157)
 UIKitCore                     	0x000000018d2b47b8 forwardTouchMethod + 236 (UIResponder.m:2170)
 UIKitCore                     	0x000000018d1b0938 -[UIWindow _sendTouchesForEvent:] + 356 (UIWindow.m:3170)
UIKitCore                     	0x000000018d1aff30 -[UIWindow sendEvent:] + 3280 (UIWindow.m:3491)
UIKitCore                     	0x000000018d1af1e4 -[UIApplication sendEvent:] + 676 (UIApplication.m:12655)
UIKitCore                     	0x000000018d1ad4d0 __dispatchPreprocessedEventFromEventQueue + 1768 (UIEventDispatcher.m:2414)
UIKitCore                     	0x000000018d1f6130 __processEventQueue + 5576 (UIEventDispatcher.m:2723)
UIKitCore                     	0x000000018d4fb114 __eventFetcherSourceCallback + 160 (UIEventDispatcher.m:2795)
CoreFoundation                	0x000000018b11c208 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1957)
CoreFoundation                	0x000000018b128864 __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2001)
CoreFoundation                	0x000000018b0ad6c8 __CFRunLoopDoSources0 + 244 (CFRunLoop.c:2038)
CoreFoundation                	0x000000018b0c31c4 __CFRunLoopRun + 828 (CFRunLoop.c:2953)
CoreFoundation                	0x000000018b0c84dc CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418)
GraphicsServices              	0x00000001c633435c GSEventRunModal + 164 (GSEvent.c:2196)
UIKitCore                     	0x000000018d45437c -[UIApplication _run] + 888 (UIApplication.m:3773)
UIKitCore                     	0x000000018d453fe0 UIApplicationMain + 340 (UIApplication.m:5363)
MobCas                        	0x0000000100300180 main + 64 (AppDelegate.swift:17)
dyld                          	0x00000001aa55cdec start + 2220 (dyldMain.cpp:1165)

クラッシュの原因

サードパーティ・ソフトウェアキーボードを使用している場合に、クラッシュする場合があるという物のようです。
SnowGirls氏が再現用のレポジトリを公開しています。

対応方法

SnowGirls氏が対応方法をレポジトリ内で公開していますが、少し冗長なので整理した物で対応しました。
（xxx_にしていますが、適当なアプリケーションプレフィックスを付けて利用してください）

@interface UITouch (UIResponderForwarderPatch)
@end

@implementation UITouch (UIResponderForwarderPatch)

+ (void)load {
    [super load];

    SEL sel = NSSelectorFromString(@"_wantsForwardingFromResponder:toNextResponder:withEvent:");
    Method originalMethod = class_getInstanceMethod(self, sel);
    if (originalMethod != NULL) {
        method_exchangeImplementations(originalMethod,
                                       class_getInstanceMethod(self, @selector(xxx_original_wantsForwardingFromResponder:toNextResponder:withEvent:)));
        method_exchangeImplementations(class_getInstanceMethod(self, @selector(xxx_wantsForwardingFromResponder:toNextResponder:withEvent:)),
                                       originalMethod);
    }
}

- (BOOL)xxx_wantsForwardingFromResponder:(UIResponder *)arg1 toNextResponder:(UIResponder *)arg2 withEvent:(UIEvent *)arg3 {
    NSString* responderClassName = NSStringFromClass([arg2 class]);
    if ([responderClassName isEqualToString:@"_UIRemoteInputViewController"]) {
        BOOL isDeallocating = NO;

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
        SEL sel = NSSelectorFromString(@"_isDeallocating");
        isDeallocating = [arg2 respondsToSelector:sel] && [arg2 performSelector:sel];
#pragma clang diagnostic pop

        if (isDeallocating) {
            return YES;
        }
    }
    return [self xxx_original_wantsForwardingFromResponder:arg1 toNextResponder:arg2 withEvent:arg3];
}

- (BOOL)xxx_original_wantsForwardingFromResponder:(UIResponder *)arg1 toNextResponder:(UIResponder *)arg2 withEvent:(UIEvent *)arg3 {
    return NO;
}

@end

skyplace

動的アクター分離チェックの調査方法

[Swift6] アクター分離境界 (Actor isolation boundary) を考慮したcallback

関連記事

同期関数のcallbackとは

異なるアクター上でcallbackが呼び出される場合

同じアクター上でcallbackを呼び出す場合

1. 呼び出し側でActorを指定する

2. GlobalActorを用いる

3. asyncにする

従来実装(non-Sendable)の挙動

動的アクター分離チェック

non-Sendableで良い場合

[Swift6] アクター分離境界 (Actor isolation boundary) を考慮したasync関数の定義パターン

前提

async関数が呼び出された時の実行スレッド

アクターのasync関数の場合

1. sendingを用いる

2. GlobalActorを用いる

アクター以外のasync関数の場合

isolationの指定をする

参考文献

[Swift6] アクター分離境界 (Actor isolation boundary) を理解する

ActorとActor isolation boundaryの基本的な考え方

ActorとExecutor

Actor isolation boundaryとSendable

Region based isolation

同時実行制御の為の1単位としてのActor

GlobalActor

nonisolated

isolated

参考文献

Combineの実行タイミングについて理解する

環境

Scheduler

実行スレッド

Combine.Published

排他制御

ImmediateSchedulerの場合

SerialQueueの場合

Subscribe Scheduler

タイミング制御

「きみの色」の解釈について

トツ子が見る色とは？

トツ子はファンタジックな能力を持っていない

それぞれのキャラの色の意味

悩みと成長

トツ子の場合

きみとルイの場合

現代における宗教の役割

SwiftUIでPreviewの内容が実体と異なる場合がある話

結論

発生条件と再現方法

iOS17 Simulatorだとin-app purchaseのテストでSKError.Code.unknownが返る問題の対策

iOSアプリにビルドハッシュを組み込む方法

xcconfigの設定

Pre-actionsの設定

Envをアプリ内から読めるようにする設定

_UIResponderForwarderWantsForwardingFromResponderのクラッシュへの対応方法

クラッシュの原因

対応方法

従来実装(`non-Sendable`)の挙動

`non-Sendable`で良い場合