SwiftはクロージャをCおよびObjective-Cに対してコンパイラ生成のスンク関数と特定のメモリレイアウト変換を通じてブリッジします。@convention(c)の場合、コンパイラはクロージャが空のキャプチャリストを持つことを要求します。これは、C関数ポインタがコンテキストパラメータなしの生のアドレスであり、外部スコープ変数への参照を防止します。@convention(block)の場合、コンパイラはヒープ上にObjective-Cブロック構造を生成し、isaポインタ、フラグ、呼び出し関数ポインタ、キャプチャされた変数のレイアウトを含むため、ARCがブロックのライフタイムを保持/解放のサイクルを通じて管理できます。重要な不変条件は、@convention(c)のクロージャがヒープ割り当てされたオブジェクトへの参照をキャプチャしてはいけないことで、ダングリングポインタを避けるためです。一方、@convention(block)のクロージャは、キャプチャされた参照がObjective-Cコード内でのブロックの存在期間中に保持されることを保証する必要があります。
リアルタイム音声処理ライブラリを開発している際に、チームはCore AudioのC API（AURenderCallback）にコールバック関数を登録する必要があり、また、UIKitのObjective-CベースのアニメーションAPIに完了ハンドラを公開する必要がありました。主な課題は、selfと音声バッファの状態をキャプチャしたSwiftのクロージャを、メモリ安全性を侵害したり保持循環を招いたりせずに、これらの外部関数インターフェースに渡すことでした。この制約は、リアルタイム音声スレッドとメインUIスレッド間のスレッド安全性を維持しながら、音声バッファへのゼロオーバーヘッドアクセスを求めました。
考慮されたアプローチの一つは、Cコールバック用にグローバル静的関数を持つシングルトンマネージャを使用することでした。この方法は、オーディオユニットポインタでキー付けされたスレッドローカル辞書にコンテキストを保存しました。このアプローチはキャプチャの問題を回避しましたが、スレッド安全性の複雑さとテストが困難なグローバル可変状態を引き起こしました。
別のアプローチは、Swiftのクロージャを保持するObjective-Cラッパークラスを作成し、このラッパーを介してデレファレンスされたC関数ポインタを公開することでした。状態を持つ一方で、これはブリッジのオーバーヘッドを追加し、早期に解放されるのを防ぐために手動の保持/解放呼び出しを必要としました。手動のメモリ管理は、ラッパーのライフサイクルがオーディオユニットの初期化と終了と正しく同期されていない場合にリークのリスクを伴いました。
選択された解決策は、SafeBitCastコンテキストポインタを持つ構造体を渡すことで、Core Audioコールバックに@convention(c)を利用し、さらにUIKitの完了用に@convention(block)を利用しました。これにより、グローバル状態を排除し、ARCがObjective-Cブロックを正しく管理することを保証しました。明示的なメモリバリアが音声スレッドの遷移中にCコンテキストポインタを保護しました。
その結果、決定論的なメモリ使用量を持つゼロオーバーヘッドのCブリッジが得られました。システムはUIレイヤーに保持循環を示さず、音声処理はグローバルロックなしでリアルタイムのパフォーマンス制約を維持しました。
なぜSwiftは言語レベルで@convention(c)クロージャ内でのキャプチャを禁止しているのか？
C関数ポインタは、暗黙のコンテキストや「ユーザデータ」パラメータのサポートなしに単純なメモリアドレスとして表現されます。これは、外部変数をキャプチャするクロージャには、Cコードが提供できない参照を格納する場所が必要であることを意味します。Swiftは、開発者がスタックまたはヒープメモリを参照するクロージャを誤って作成するのを防ぐために、この制約をコンパイル時に強制します。そのような参照は、C関数ポインタがSwiftコンテキストよりも長生きする場合にダングリングポインタになります。
@convention(block)クロージャがObjective-Cコードに渡されて現在のスコープを超えて保存される場合、ARCはどのようにライフサイクルを管理するのか？
Swiftがクロージャを@convention(block)に変換すると、コンパイラはヒープ上に割り当てられたObjective-Cブロック構造を生成します。この構造は、NSObjectメモリレイアウトに従い、ブロックが境界を越える際にARCがBlock_copyおよびBlock_release操作を適用できるようにします。Objective-Cコードがブロックをインスタンス変数に保存する場合、SwiftのARC統合はキャプチャされたSwift参照が保持されることを保証します。これらの参照は、Objective-Cホルダーがブロックを解放するときに解放され、マニュアル保持管理を避けながら使用後の解放を防ぎます。
@convention(c)関数型のメモリレイアウトと標準Swiftクロージャ参照の違いは何ですか？
標準のSwiftクロージャは、変数をキャプチャできる参照カウントされたヒープオブジェクトまたはスタックに割り当てられたコンテキストペアです。それとは対照的に、@convention(c)関数型は、生の関数アドレスを表す単一の機械単語にコンパイルされます。それには関連するメタデータ、保持カウント、またはキャプチャコンテキストはありません。この区別は、標準のSwiftクロージャが動的にディスパッチされ、メモリを管理できるのに対し、@convention(c)クロージャが明示的なUnsafeMutableRawPointerコンテキストパラメータを必要とする静的アドレスであることを意味します。