仕様書

作成

[36] MessagePort インターフェイスはコンストラクターを持ちません。

[37] 作成するには、 MessageChannel オブジェクトなどを作成する必要があります。

[39] 環境設定群オブジェクト所有者に関する新しいMessagePortオブジェクトの作成 (create a new MessagePort object) は、次のようにしなければなりません。

[41] ポートを、新しい MessagePort に設定します >>32。
[42] MessagePort
所有者
所有者
[128] (イベントループのタスクキュー群のいずれかのタスクキューにおいて、 ポートのポートメッセージキューがタスクキュー部分リストの1つとなります。)
[127] ポートを返します >>32。

[40] この処理は、次の場面から呼び出されます。

文脈

[33] MessagePort インターフェイスは、文書環境とワーカー環境と AudioWorklet に晒されています >>32。

[96] MessageChannel オブジェクトを作成すると、 port1 と port2 の2つの IDL属性から MessagePort にアクセスできます。

[98] postMessage メソッドで送信する MessagePort を指定できます。

[97] postMessage の受信やワーカーの作成で MessageEvent イベントが発火された時は、 ports IDL属性で MessagePort の配列にアクセスできます。

[100] ワーカーは、暗示的ポートとして MessagePort を持ちます。

[101] SharedWorker オブジェクトは、 port IDL属性で MessagePort を持ちます。

[99] WorkerGlobalScope は、ワーカーのポート群 (the worker's ports) として MessagePort のリストを保持しています >>149。

ワーカー内で作成されたポートが自動的に追加されます。暗示的なポートも含まれます。

[170] protected worker かどうかの判定で参照されます。

[171] ワーカーを走らせる処理の最後の片付けの段階で disentangle の実行のため参照されます。

[150] 同様に Window もポート群を持つと考えられます (>>107)。

状態

[38] EventTarget としての状態に加えて、次の状態を持ちます。

entangle されたポート >>32: 他の MessagePort オブジェクト。 >>107 も参照。
ポートメッセージキュー: タスク源。タスクキュー部分リストと捉えることもできます。初期状態は空です。有効か無効かのいずれかの状態を持ち、その初期状態は無効です。
既に出荷済みフラグ: ブール型。初期状態は偽。
所有者 (owner): 環境設定群オブジェクト。 >>32

メンバー

[34] EventTarget を継承しています >>32。

[35] 加えて、次のメンバーがあります。

ポートメッセージキュー

[135] MessagePort オブジェクトは、ポートメッセージキュー (port message queue) を持ちます。初期状態は空です。 >>65

[136] MessagePort オブジェクトのポートメッセージキューは、無効 (disabled) または有効 (enabled) のいずれかの状態にあります。初期状態は無効です。一旦これを有効にすると、無効には戻せません。 >>65

[125] ポートメッセージキューは、タスクキュー部分リストと理解できます。タスクキューを参照。

[137] MessagePort オブジェクトは、既に出荷済み (has been shipped) フラグを持ちます。初期状態は偽です。 >>32

[142] 未出荷済み

[64] 2つの状態が、 postMessage の結果生じる message イベントの実行タイミングに影響します。仕様書の規定は複雑でわかりにくいですが:

既に出荷済みフラグが偽
- ポートメッセージキューの状態が有効
  - ポートメッセージキューは実行されない
  - 未出荷済みポートメッセージキューに含まれる
- ポートメッセージキューの状態が無効
  - ポートメッセージキューは実行されない
  - 未出荷済みポートメッセージキューに含まれない
既に出荷済みフラグが真
- ポートメッセージキューの状態が有効
  - ポートメッセージキューは実行される
  - 未出荷済みポートメッセージキューに含まれない
- ポートメッセージキューの状態が無効
  - ポートメッセージキューは実行されない
  - 未出荷済みポートメッセージキューに含まれない

... 整理してみると単純な話で、キューの状態が有効なら実行され、出荷済みならポートメッセージキュー扱い、未出荷なら未出荷済みポートメッセージキュー扱いになる、ということです。

[143] ポートメッセージキューと未出荷済みポートメッセージキューは、タスクのキューであるにも関わらず、タスク源である >>32 と規定されています。それでいて、イベントループによって (実行されるべきタスクのリストとして) 使われる >>32 ともされていて、イベントループの持つタスクキューの一種であるかのようにも捉えられます。

[144] 仕様書の履歴を辿ってみると、元はポートメッセージキューはその名の通り message イベントのキューでした。このキューに追加されたイベントは、(準備が整い次第) イベントを発火するタスクがイベントループのタスクキューに追加され、ポートメッセージキューからは削除されることになっていました。

[145] これがその後の改訂 >>133 で、ポートメッセージキュー自体がタスクのキューになりました。コミットメッセージで MessagePort が他のイベントループに渡った時にイベントが失われないための変更だと説明されており、 MessagePort の Transfer でイベントを新イベントループ下に移動させることが狙いだったようです。

[146] この変更で、ポートメッセージキューはタスク源であるということになりました。仕様書は「タスクはタスク源から来る」としか言っておらず、タスク源とは何なのか (ラベルなのかリストなのか) はよくわかりませんが、 (実装でどう扱うかは別として、仕様書の裏の考え方としては) タスク源とはそれ自体がタスクのリスト (タスクキュー部分リスト) で、そのようなリストをいくつか束ねたものがタスクキューだ、といえるのかもしれません。

タスクキュー参照。

[63] クライアントメッセージキューと似ています。

処理

entangle

[43] 2つの MessagePort を関連付けた状態とすることを entangle といいます。 ポート1とポート2の entangle は、次のようにしなければなりません。

[44] ポート1の entangle されたポートが null でなければ、
1. [45] ポート1の disentangle を実行します。 >>32
[46] ポート2の entangle されたポートが null でなければ、
1. [47] ポート2の disentangle を実行します。 >>32
[48] ポート1の entangle されたポートを、ポート2に設定します。 >>32
[49] ポート2の entangle されたポートを、ポート1に設定します。 >>32
[151] ポート1の所有者とポート2の所有者が異なるなら、 (>>107)
1. [152] ポート1の所有者の大域オブジェクトのポート群に、 ポート1を追加します。
2. [153] ポート2の所有者の大域オブジェクトのポート群に、 ポート2を追加します。

[51] entangle は、次の場面で呼び出されます。

[50] この処理が済んだ状態を、ポート1とポート2が entangle されている (entangled) といいます >>32。

[102] entangle 状態を解除することを、 disentangle >>32 といいます。 MessagePort ポートの disentangle は、次のようにしなければなりません。

[103] ポートの entangle されたポートの entangle されたポートを、 null に設定します。
[155] ポートの entangle されたポートの所有者の大域オブジェクトのポート群から、 ポートの entangle されたポートを (あれば) 削除します (>>107)。
[104] ポートの entangle されたポートを、 null に設定します。
[154] ポートの所有者の大域オブジェクトのポート群から、 ポートを (あれば) 削除します (>>107)。

[105] disentangle は、次の場面で呼び出されます。

entangle
close メソッド
ワーカーを走らせる処理の最後の破棄の段階

[106] entangle の中から disentangle が呼び出される、つまり entangle 関係が書き換えられて他の MessagePort と関連付けられた状態になるのは、 Transfer からの呼び出しの場合のみです。すなわち postMessage により MessagePort が送られて、他方の MessagePort の接続先が新しい方に差し替えられる場合です。これ以外で disentangle された MessagePort は、二度と entangle されることはありません。

transfer

[52] MessagePort オブジェクトは、 transferable object です。 >>32

[53] MessagePort オブジェクトの transfer steps は、値とデータ保持子について、次のようにしなければなりません >>32。

[54] 値を出荷します。
[165] データ保持子の PortMessageQueue を、 値のポートメッセージキューに設定します。
[58] 遠隔ポートを、文脈オブジェクトの entangle されたポートに設定します。
[59] 遠隔ポートが null 以外なら、
1. [60] 遠隔ポートを出荷します。
2. [166] データ保持子の RemotePort を、遠隔ポートに設定します。
[167] それ以外の場合、
1. [168] データ保持子の RemotePort を、 null に設定します。

[169] transfer-receiving steps は、データ保持子と値について、次のようにします >>32。

[84] 値を出荷します。
[55] 値の所有子を、 値の関連設定群オブジェクトに設定します。
[57] データ保持子の PortMessageQueue が空でなければ、繰り返し、
1. [123] タスクを、 データ保持子の PortMessageQueue を dequeue した結果に設定します。
2. [124] タスクを値に transfer (>>126) します。
[56] データ保持子の RemotePort が null 以外なら、
1. [61] データ保持子の RemotePort と値を entangle します。

[126] 旧タスクの新ポートへの transfer は、次のようにしなければなりません。

[138] タスクをキューに追加します。
イベントループ
新ポートの所有者の有責イベントループ
処理
引数付きのアルゴリズム
変数
最終対象ポート
新ポート >>92
処理
旧タスクの処理の処理
タスク源
新ポートのポートメッセージキュー >>32
文脈
新ポートの所有者 >>32

[140] 仕様書ではタスクをキューに追加する操作を使わずに記述されています。

ポートの状態の変更

[67] MessagePort ポートのポートメッセージキューの有効化は、次のようにしなければなりません >>32。

[70] ポートのポートメッセージキューの状態を、有効に設定します。

[68] これによって、それまでイベントループのタスクキューの処理で無視されていた本ポートメッセージキューのタスクが、処理対象にと変化します。

タスクキュー参照。

[91] 次の場面で呼び出されます。

[130] クライアントメッセージキューの startMessages メソッドに相当します。

[85] MessagePort ポートの出荷は、次のようにしなければなりません >>32。

[86] ポートの既に出荷済みフラグを、真に設定します。
[69] ポートについてポート出荷に伴うタスク移動を行います。

[87] HTML Standard では、これは Transfer (>>53) から実行される処理となっています。意味的には、それ以外にワーカーを走らせる処理、 new Worker、 new SharedWorker からも実行されるべきではないかとも思われますが、そうは規定されていません。歴史的経緯による誤りなのか、意図通りなのかははっきりしません。現実問題どれだけその差が観測できるかは微妙なところかもしれません。

それぞれの項も参照。

ポートメッセージキューの操作

[71] 処理を MessagePort ポートのポートメッセージキューに追加するには、次のようにしなければなりません。

[138] タスクをキューに追加します。
イベントループ
ポートの所有者の有責イベントループ
処理
引数付きのアルゴリズム
変数
対象Realm
ポートの関連Realm >>92
処理
処理
タスク源
ポートのポートメッセージキュー >>92
文脈
ポートの所有者 >>92

[147] 仕様書ではタスクをキューに追加する操作を使わずに記述されています。

[129] これは postMessage から呼び出されます。

ごみ収集

[107] MessagePort ポートが entangle されているなら、次のいずれかとしなければなりません >>108。

[118] ポートのentangle されているポートからポートへ、強い参照が存在する。
[119] ポートの所有者の大域オブジェクトからポートへ、強い参照が存在する。

[120] 実装上、 entangle されているポート同士が異なるプロセスで動作しているなど、直接強い参照を保持しているとすると実現困難な場合があるため、 2つの方法が認められているものと思われます。2つの方法は完全に等価なわけではありませんが、著者のスクリプトから直接観測可能な挙動としては同一です。

[139] ワーカーに関しては、 WorkerGlobalScope のワーカーのポート群として当該ワーカー外に entangle されたすべての MessagePort のリストを大域オブジェクトが保持することになっています。これは事実上 >>119 を求めるものです (他の等価な実装方法も理論上はあり得ますが...)。文書環境に関しても、同様に MessagePort のリストを保持するのが現実的でしょう。

[157] 実装上は、 disentangle されないまま両端ともスクリプトから参照されなくなった時に、ポート群から除去されてこれらがごみ収集されるよう、注意が必要です。

[148] 同じ環境内のポート同士は、 >>118 の方法を採っても、 >>119 の方法に準ずることにしても良さそうです。

[121] MessagePort がごみ収集されないということは、そこに登録されたイベントリスナーがごみ収集されないということです。つまりこの要件は、イベントリスナーを登録した後に MessagePort への参照が破棄されたとしても、相手方のポートが生きている限りはイベントリスナーが呼び出される可能性を維持するためのものです。

[122] もちろん、両側の MessagePort が共に参照されない状態になった場合は、もうイベントリスナーが呼び出される可能性はありませんから、両方共に破棄できます >>108。

[109] 未実行のタスクと MessagePort のごみ収集の関係として、次のように規定されています。

[113] 当該オブジェクトでイベントをディスパッチするタスクがタスクキューに入っているなら、ごみ収集してはならない >>108。
[114] 当該オブジェクトのポートメッセージキューの状態が有効で、ポートメッセージキューが空ではないなら、ごみ収集してはならない >>108。

[115] このうち >>113 は通常のタスクであれば当然にタスクからイベント対象への強い参照が維持されているはずと考えられるところ、 message については実行時点で含まれるポートメッセージキューの MessagePort をイベント対象とする (>>71) との変則的な規定があるための条件なのでしょうか。

[116] >>114 は、逆に言えばポートメッセージキューが無効の場合は実行されずに捨てられる (かもしれない) し、空になったら捨てられる (かもしれない) ということです。

[117] >>113 は >>114 に含まれるようにも読めますが、イベントループがタスクを実行しようとしてポートメッセージキューから取り出した瞬間に空になって MessagePort が破棄されないために >>113 が必要なのでしょうか。と思いましたがタスクは実行が終わるまでタスクキューに残ったままですよね...

[131] >>113 はタスクキューにタスクが入っていれば、という規定になっていて、ポートメッセージキューとは言っていません。ポートメッセージキューはタスク源であるとはされていますが、タスクキューとはされていません (いかにもタスクキューっぽい名前ですが)。従ってポートメッセージキューが無効なら、 >>113 の条件には合致しないものと思われます。 (無効のまま MessagePort が破棄されたなら、有効化する手段がなくなるので、捨てても捨てなくても観測できません。)

[156] 現実には MessagePort が無効のまま破棄された時、タスクキュー内にポートメッセージキューのタスク (がイベント対象として保持している MessagePort 自身への参照) もごみ収集されるよう、注意する必要があります。

`MessageChannel` インターフェイス `port1` 属性、 `port2` 属性

[27] MessageChannel インターフェイスの port1 IDL属性と port2 IDL属性 >>26 は、それぞれ文脈オブジェクトのポート1とポート2を返します。

[28] MessageChannel オブジェクトのポート1とポート2は、コンストラクターによって新たに作成された MessagePort オブジェクトがそれぞれに設定されます。これらの値は変化することはありません。

[29] 2つのポートは、作成された時点では (異なるオブジェクトであることを除けば) まったく同じ初期状態です。どちらをどう使うかは、著者が決めることができます。

[30] 例えば port1 の側を postMessage で通信の相手先に渡したら、以後のこちら側の送受信には port2 を使うことになります。逆に port2 を渡したら、 port1 を使うことになります。

`MessagePort` インターフェイス `start` メソッド

[88] MessagePort インターフェイスの start メソッドは、次のようにしなければなりません >>32。

[89] 文脈オブジェクトのポートメッセージキューの状態が無効なら、
1. [90] 文脈オブジェクトのポートメッセージキューの有効化を実行します。

`MessagePort` インターフェイス `close` メソッド

[93] MessagePort インターフェイスの close メソッドは、次のようにしなければなりません >>32。

[179] 文脈オブジェクトの Detached を、真に設定します。
[94] 文脈オブジェクトのentangle されたポートが null 以外なら、
1. [95] 文脈オブジェクトの disentangle を実行します。

[112] MessagePort が不要になったら、明示的に閉じて disentangle することが強く勧められています (strongly encouraged) 。明示的に閉じずないと必ずしも即座にごみ収集されるとは限らないため (>>107)、メモリーを無駄にすることとなります。 >>108

`MessageEvent` インターフェイス `ports` 属性

[162] MessageEvent インターフェイスと MessageEventInit 辞書の ports IDL属性/辞書メンバー >>161 は、受信した MessagePort の配列を表します。

[163] 値は MessagePort の sequence です >>12。辞書での既定値は空の配列です >>12。

歴史

[72] [] (0) Simplify message ports: use queueing instead of transient 'act… (Hixie著, 2008-08-06 16:24:38 +09:00) https://github.com/whatwg/html/commit/ebefa1c712950ea904e2e4877caa13db8b1d9104

[73] ポートメッセージキューはここで導入されました。 open と closed の2つの状態を持っていました。この時同時に追加された start メソッドを呼び出すか、 onmessage IDL属性に値を設定するかのいずれかにより、 closed から open へと遷移することとされていました。