Workerと共有メモリー

Web Workerは別のグローバル環境で実行され、メインスレッドと並行して処理できます。通常のpostMessageは構造化複製を使い、Transferableオブジェクトは所有権を移します。SharedArrayBufferは複数の実行エージェントが同じ基盤メモリーにアクセスできる仕組みですが、使えば常にコピーがなくなり高速になるわけではありません。バッファー構造、仕事の分割、同期、終了処理はアプリケーション側で設計します。

Atomicsによる同期

共有メモリーへの通常の読み書きだけでは、エージェント間の同期順序は定まりません。Atomicsは共有整数型TypedArrayに対する原子的操作と順序制御を提供し、カウンター、フラグ、キューの状態遷移に利用できます。Atomics.wait()でブラウザーのメインスレッドをブロックすることはできず、Workerなど許可された実行環境で待機します。配列型やメモリーモデルはECMAScript仕様に従います。Atomicsを使ってもデッドロックや不適切な同期設計が自動的に解消するわけではありません。

ブラウザーのcross-origin isolation条件

現行ブラウザーでWebページからSharedArrayBufferを使うには、通常cross-origin isolatedなコンテキストが必要です。一般的にはトップレベル文書にCross-Origin-Opener-Policy: same-originとCross-Origin-Embedder-Policy: require-corpを設定し、対応環境ではcredentiallessを選択肢にして、self.crossOriginIsolatedを確認します。COEP下のクロスオリジン下位リソースはCORSまたはCORP応答で許可される必要があります。iframeにはPermissions Policyや祖先・子文書全体の隔離条件が加わることがあります。利用ブラウザーと埋め込み状況ごとに確認してください。

セキュリティヘッダーの影響

COOPはウィンドウ間の閲覧コンテキスト関係やopener通信を変え、COEPは明示的に許可されない埋め込みリソースを遮断し得ます。そのためOAuthポップアップ、決済ウィンドウ、広告・分析スクリプト、外部画像に影響する場合があります。Report-Onlyで問題を観察してから適用します。隔離は機能を有効にするブラウザー側の条件であり、OSプロセスが必ず分離される保証や、あらゆるサイドチャネル攻撃への免疫を意味しません。

ブラウザー専門家による実装上の確認

Google Chrome Developersのブラウザー専門家向けweb.devガイドは、COOP・COEP導入時に下位リソースのCORS/CORP、iframe全体の隔離チェーン、crossOriginIsolatedの確認が必要と説明します。これは実装上の助言で、ブラウザー標準そのものではありません。対象ブラウザーで機能検出、Worker通信、外部リソース、ポップアップを試験します。対応状況は更新されるため、特定の版数を一律の条件とせず、最新の互換性情報と実行時状態を確認してください。

参考資料