翻訳 executor -> エグゼキュータ

Guide.docc/IncrementalAdoption.md

@@ -389,7 +389,7 @@ final class MyJetPack: NSJetPack {
 
 > 注記: このような問題に遭遇し、ドキュメントやAPIのアノテーションを調査して何か間違ったアノテーションがされていると判断したとき、問題の根本原因を解決する最善の方法はライブラリのメンテナに問題を報告することです。
 
-見ての通り、ランタイムは呼び出しにエクセキュータ確認を注入し、（メインアクター上で実行される）ディスパッチキューのアサーションに失敗しています。
+見ての通り、ランタイムは呼び出しにエグゼキュータ確認を注入し、（メインアクター上で実行される）ディスパッチキューのアサーションに失敗しています。
 これにより見えづらくデバッグしにくいデータ競合を防いでいます。
 
 この問題に対する長期的な視点で正しい解決策は、 `nonisolated` をつけることでライブラリのメソッドのアノテーションを修正することです：
@@ -431,7 +431,7 @@ let lotsOfWork: [Work] = ...
 await withTaskGroup(of: Something.self) { group in
   for work in lotsOfWork {
     // WARNING: もしもこれが数千もの項目なら、
-    //  同時に実行するタスクの数（システムのコア数に依存）とデフォルトのグローバルエクセキュータの設定にグローバルな制限があるため、
+    //  同時に実行するタスクの数（システムのコア数に依存）とデフォルトのグローバルエグゼキュータの設定にグローバルな制限があるため、
     //  かなり後になってからでないと実行されないタスクが多数作成される可能性がある。
     group.addTask {
       await work.work()
@@ -446,7 +446,7 @@ await withTaskGroup(of: Something.self) { group in
 
 何百または何千もの項目を扱うつもりなら、それらをすべて一気にタスクグループに追加するのは非効率的かもしれません。
 メモリ量はさほど大きくない一方で、タスクを（`addTask` で）作成するにはタスクに中断と実行のためのメモリをいくらか割り当てる必要があります。
-ただちに実行されずエクセキュータが実行するまで待機するだけのタスクを何千個も作成した場合に大きな影響を及ぼす可能性があります。
+ただちに実行されずエグゼキュータが実行するまで待機するだけのタスクを何千個も作成した場合に大きな影響を及ぼす可能性があります。
 
 このような状況に直面した場合、次のように、タスクグループに同時に追加されるタスクの数を手動で調整するとよい場合があります：
 
@@ -494,4 +494,4 @@ struct Work {
 ```
 
 明示的な中断ポイントの導入は、Swiftがこのタスクの進捗とプログラム内の他のタスクの作業の進捗のバランスをとるのに役立ちます。
-しかし、システムのなかでこのタスクが最も優先順位が高い場合、エクセキュータはただちに同じタスクの実行を再開します。そのため、明示的な中断ポイントで必ずしも資源飢餓を避けられるわけではありません。
+しかし、システムのなかでこのタスクが最も優先順位が高い場合、エグゼキュータはただちに同じタスクの実行を再開します。そのため、明示的な中断ポイントで必ずしも資源飢餓を避けられるわけではありません。