イベントループ (Web)

[3] Webブラウザーにおけるイベント、fetch、構文解析、スクリプト実行、レンダリングその他の動作の相互作用は、イベントループ (event loop) によって説明されています。

[15] 非同期システム、 GUI システムの同様の概念に倣ってイベントループと呼ばれていますが、実際に Webブラウザーで実行される処理の単位はイベントではなく、タスクと呼ばれています。 JavaScript で利用される DOM のイベントはタスクであることもあれば、タスクの処理の一部分であることもあります。

[81] 入出力装置やネットワークの入出力のような Webブラウザー外の“イベント” は、それを処理するタスクとして Webブラウザーのイベントループにおけるタスクキューに追加されることになります。

[207] 1つのWebブラウザー上では、複数の Webサイトなどが同時にレンダリング・動作しています。単一のWebページも、閲覧文脈本体の他、複数のワーカーが並行して動作することがあります。そのためイベントループも同時に複数存在することがあります。

仕様書

イベントループ

[6] 利用者エージェントは、イベント、利用者との対話、スクリプト、レンダリング、ネットワーク処理、その他の協調のためにイベントループを使わなければなりません。イベントループは利用者エージェント毎に少なくても1つなければなりません。関係する類似起源閲覧文脈の単位毎に高々1つのイベントループを有することができます。 >>5

[8] つまり、利用者エージェント全体で1つのイベントループを共有することもできますし、タブ毎などの単位で複数のイベントループに分けることもできるのですが、その分け方として、 (document.domain を考慮した) 起源ごとのグループを分離してはいけない、ということです。

[9] 仕様上明記されていませんが、おそらくここでいう「利用者エージェント」の単位は恣意的に決めることができ、例えば通常モードと秘密モードがあり、両者で開いている Web頁同士が同じ起源であっても JavaScript でアクセスできないなら、これは2つの利用者エージェントであり、この規定に違反せずに別々のイベントループを有することができるはずです。

[7] 1つの関連する類似起源閲覧文脈の単位に対して複数のイベントループがあると、そこに属するいずれかの閲覧文脈が他の関連する類似起源閲覧文脈の単位に属するような navigate が発生した時に複雑なことになります。 HTML 仕様はそれをどう処理するか現在定義していません。 >>5 (複雑なこと、というのは具体的には示されていません。)

[11] イベントループのすべての閲覧文脈が捨てられる時、イベントループ自体も捨てられます。逆に閲覧文脈は1つイベントループを持ちます。

[91] ワーカーのイベントループは閲覧文脈ではなく、ワーカーに関連付けられています。ワーカーが閉じられた時にイベントループも捨てられます。

[93] サービスワーカーを走らせる処理でもイベントループが作られます。

[71] 「要素のイベントループ」は明確に定義されていませんが要素の節点文書が属する閲覧文脈が属するイベントループを指すようです。

用例:

HTML Standard (2012-11-16 20:26:18 +09:00 版) http://www.whatwg.org/specs/web-apps/current-work/#commit-the-scratch-bitmap

状態

[55] イベントループは次の状態を持ちます。

種別: メインのイベントループか、ワーカーのイベントループのいずれかです。
タスクキュー群: イベントループは、1つ以上のタスクキューを持ちます >>5。個数と使い分けは実装に依存します。
マイクロタスクキュー
閲覧文脈群またはワーカー: [10] ワーカー以外のイベントループは、最低1つ閲覧文脈を持ちます >>5。 [42] ワーカー (WorkerGlobalScope) は、それぞれ別個のイベントループを有します >>40, >>204。
文書群: レンダリングの更新、アイドル期間の開始、アイドルコールバック群呼び出しアルゴリズムで参照されます。
現在走っているタスク: 動作中のタスクまたはマイクロタスクが高々1つ存在します。
一時停止中
termination nesting level >>90: モーダルダイアログの表示を制御するものです。
マイクロタスクチェックポイントを行っている
環境設定群オブジェクト群: 有責イベントループが本環境設定群オブジェクトであるようなイベントループ >>92 の弱集合。マイクロタスクチェックポイントの実行で参照されます。
JavaScript実行文脈スタック: (どの仕様書も明言していないようですが、イベントループごとに1つあると思われます。)
バックアップ現職設定群オブジェクトスタック
BroadcastChannel群
最終アイドル期間締切
活性スクリプト
イベントループ開始
イベントループ終了

[12] ストレージミューテックス: ストレージへのアクセスを制御するためのミューテックスを保持した状態になることがあります。
[39] ストレージミューテックスは利用者エージェント全体で1つなので、ストレージミューテックスの解放待ちのためにイベントループ全体がブロックされることがあります。

[161] イベントループが実行する処理の単位はタスクと呼ばれます。特定のイベントループが同時に実行するタスクは高々1つであり、現在走っているタスク (currently running task) と呼ばれます。現在走っているタスクの初期値は null です。 >>5

[163] 現在走っているタスクはイベントループ全体によってタスクに設定される場合 (>>13) の他、マイクロタスクチェックポイントによってマイクロタスクに設定される場合もあります。

[63] レンダリングの更新からは現在走っているタスクは設定されないので、アニメーションフレームコールバックの実行中は null のままです。

[195] 現在走っているタスクは、 (仕様書上必ずしも明示はされていませんが) タスク内の各アルゴリズムから、そのタスクの種類を調べるため参照されます。例えば allowed to show a popup は、クリック系のイベントに由来するタスクの処理中かどうかで分岐します。

[217] スクリプトを走らせる準備は現在走っているタスクを参照しています。

実行

[13] メインやワーカーのイベントループイベントループは、次のようにしなければなりません >>5。

[233] 繰り返し、
1. [235] イベントループの実行中断中 (>>30, >>218) でなければ、
  1. [74] タスクを、 イベントループにおけるタスクの処理 (>>75) をした結果に設定します。
  2. [184] イベントループについて、マイクロタスクチェックポイントを行います。
  3. [248] 今を、現在高分解能時刻に設定します。
  4. [249] タスク開始時刻とタスクと今について、タスクの時間長を報告します (>>250)。
  5. [186] 文書群を、 イベントループと今について、レンダリングの更新をした結果に設定します。
  6. [133] イベントループについて、アイドル時の処理 (>>135) を実行します。
  7. [134] イベントループと文書群と今について、レンダリングの更新の時間長を報告します (>>257)。
  8. [187] イベントループの終了条件 (>>108) を満たす場合、
    1. [188] イベントループを破棄 (destroy) してここで停止します。

[16] イベントループとは別に、算法の一部分が非同期的に実行されると規定されているものがあります。そのような算法についても、結果を何らかの形で DOM に反映させる必要があり、イベントループが安定状態を提供することによってそのような算法の同期区間が実行される、あるいはタスクキューにタスクを追加する、といった形でイベントループと統合されています。マルチスレッドな実装なら同期区間の前後の非同期な部分はイベントループとは別のスレッドで実装してもよいでしょうし、単一スレッドなら仕様上のイベントループを含むより大きなイベントループの中で交互に処理を行うことになるのでしょう。 (単一スレッドの Webブラウザーがあるのか知りませんが...)

[53] イベントループの手順中でタスクとマイクロタスクの実行では著者によるスクリプトが実行される可能性があります。またレンダリングの更新でもアニメーションフレームコールバックなどとして著者によるスクリプトが実行されることがあります。

[130] アイドル状態になったと判定すると、 requestIdleCallback のコールバック関数の実行のためのタスクをキューに追加することになっています。

アイドル状態を参照。

タスクの実行

[75] イベントループのタスクの処理は、次のようにします。

[162] 「手順1」 (>>48) の処理を行います。
[238] タスクを、イベントループについてタスクキューからタスクを選択した結果に設定します。
[239] タスクが null でない場合、
1. [230] タスク開始時刻を、現在高精度時刻に設定します。
2. [179] イベントループの現在走っているタスクを、 タスクに設定します >>5。
3. [180] タスクの手順群を実行します >>5。
4. [181] イベントループの現在走っているタスクを、 null に設定します >>5。
5. [256] タスクを返します。

[76] イベントループの一巡の間にタスクは高々1つだけ実行されます。それに対してマイクロタスクやアニメーションフレームコールバックは、実行できる状態のものがすべて実行されます。これがタスクに対してマイクロタスクが「マイクロ」である所以です。

[182] かつてはタスクの実行後にストレージミューテックスの解放も行うこととされていました。

[183] かつてはタスクを実行した後でタスクキューから削除すると規定されていました。タスクキューからタスクを選択

手順1到達時点の状態

[48] 次に示すものは、「最後にイベントループの手順1に到達した時 (last time the event loop reached step 1) 」の状態を定義に含めています。

[49] スクリプトをブロックしているスタイルシート
[50] ended 属性 (媒体要素)
[57] WebSocket の bufferedAmount
[58] WebSocket のごみ収集
[65] embed 要素の potentially active
- 文書中にあるか否か
- レンダリング中であるか否か
[208] 選択状態にある video track や audio track の決定
- [209] Web Applications 1.0 r8673 Make sure that we say that enabling audio tracks and selecting video tracks is all synchronised with the event loop (2014-06-12 07:25:00 +09:00 版) http://html5.org/r/8673

[56] かつては「最後にイベントループがタスクを実行しはじめた時 (last time the event loop started executing a task) 」とも呼ばれていましたが、 >>48 の表現に統一されました。

[158] 次に示すものは、「次にイベントループの手順1に到達する前 (before the next time the event loop reaches step 1) 」を定義に含めています。

[51] 媒体要素が文書から削除された後、この時点までに再度挿入されない場合、ハードウェア資源に制約があればその機会にこれをすべて解放するのがよいとされています http://www.whatwg.org/specs/web-apps/current-work/#best-practices-for-implementors-of-media-elements。

[68] また、次に示すものは、同じタスク内であれば同じ結果になることが求められています。

[69] canvasResolution の値や、ビットマップ作成時に使う解像度

[211] 同じ「タスク」ということは、スピンによってタスクが中断された場合、再開後に同じ値であるとは限りません。

[66] これらは、次の event loop level 1 に到達する前に実装が保持する値を更新したり、新たな状態を反映させるための処理を行ったりする必要があります。

[124] embed 要素では、状態を更新するためのタスクをタスクキューに追加する必要があるかもしれません。

アイドル時の処理

[135] イベントループのレンダリングの更新の各処理とレンダリングの更新の計測の間に、次のようにします >>5。

[136] 次のすべてを満たす場合、
- [138] イベントループが window event loop であり、
- [141] イベントループのタスクキュー群のどのタスクキューにも、文書の完全に活性が真のタスクが含まれず、
- [142] イベントループのマイクロタスクキューが空であり、
- [147] イベントループの閲覧文脈のいずれもレンダリング機会を有さない
1. [148] イベントループの各閲覧文脈閲覧文脈について、
  1. [153] 閲覧文脈の Window について、アイドル期間開始アルゴリズムを実行します。

[70] requestIdleCallback のアイドル期間の決定では、レンダリングその他の内部処理のスケジューリングが影響を及ぼします。

スピン

[212] イベントループをスピン (spin the event loop) は、一種の継続で、一旦現在の処理を中断してイベントループに制御を戻し、指定した条件条件が達成された後に再開するものです。

[17] イベントループイベントループのスピンは、次のようにしなければなりません >>5。

[164] タスクを、イベントループの現在走っているタスクに設定します。
[165] タスク源を、タスクの源に設定します。
[166] 旧スタックを、イベントループのJavaScript実行文脈スタックの複製に設定します。
[167] イベントループのJavaScript実行文脈スタックを空にします。
[18] タスクを停止させます。
- [269] タスクを停止させると呼び出し元であるイベントループの手順群の次の手順へと進みます。
- [169] つまりイベントループについてマイクロタスクチェックポイントが実行されることになります。イベントループ

[173] スピンはイベントループから直接呼び出されたタスクから呼び出されることもあれば、マイクロタスクや複合マイクロタスク部分タスクから呼ばれることもあります。

[213] JavaScript実行文脈にはスクリプトの実行環境やスクリプト設定群オブジェクトその他が含まれていますので、それら処理に必要な状態すべてが保存された状態で、実行が中断され、イベントループやマイクロタスクチェックポイントなどの次のステップへと進むことになります。

[168] かつては global script clean-up jobs の実行もここで行われていました。

[19] 並列に、条件が成立するのを待ちます。成立したら、次のようにしなければなりません。 >>5

[270] タスクをタスクキューに追加します。
源
源
手順群
[170] イベントループのJavaScript実行文脈スタックを、旧スタックに設定します。
[171] スピンの呼び出し元の続きの手順群を実行します。

[140] スピンによって実行中のタスクは中断されますが、イベントループが中断しているわけではないので、スピン後に新たに追加されたタスクはそのまま実行されます。

[25] document.close はスピンするまで字句化を行います。

詳しくは document.close 参照。

[205] かつては >>160、媒体要素が文書から削除された後、次にイベントループがスピンするより前に再度挿入されない場合、ハードウェア資源に制約があればその機会にこれをすべて解放するのがよいとされていました >>159。

[159] http://www.whatwg.org/specs/web-apps/current-work/#best-practices-for-implementors-of-media-elements

スピンする状況

[21] スピンする状況

[24] script 要素の終了タグの処理
[210] stop parsing (他のスクリプトの実行やスタイル・シートの準備完了や delay the loading 待ち)

[22] update the session history with the new page (素片識別子の示す場所までスクロールするタイミング待ち)
[23] showModalDialog (ダイアログが閉じられるの待ち)

[125] stops parsing におけるスピンは、スピンを使わない形に読み替えられます。 stops parsing

[231] script 要素の終了タグの処理の場合、スピンの直前に同じ構文解析器に処理させるタスクの実行をブロックし、直後にブロック解除することになっています。従って、既に fetch が続きの部分の構文解析を求めるタスクを追加していたとしても、スピンの時点で保留タスクとなって、スピンの条件達成により追加される継続タスクが先に実行されることになります。

[232] タスクを実行しない、という処理の詳細が HTML Standard では規定されていないので、同じタスク源のタスクなのだから継続タスクは前のタスクの完了まで実行されず、デッドロックに陥る、と解釈できなくもないのですが、明らかに誤っています。

[172] HTML Standard では >>17 の通りタスクの実行を中断して条件が成立してから再開する形を採っていますが、実際の Webブラウザーでは JavaScriptエンジンの仕様上そのように中断させることは難しく、イベントループ自体を再帰的に実行しているようです。

[139] [whatwg] Bug in 12.2.5.4.8 (The "text" insertion mode) when invoking the "spin the event loop" algorithm (2013-10-01 22:14:47 +09:00 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/040949.html

[80] このうち update the session history with the new page は利用者エージェントがイベントループ上の任意のタイミングで実行できますし、スピン前の処理が後の処理に直接的に影響を及ぼしてもいないため、実質的に次の処理のためのタスクをキューに入れるのと変わらないと思われます。

字句化器のブロック

[59] script 要素の処理でスピンする場合、その直前に HTML 字句化器やXML構文解析器がブロックされ、直後にブロックが解除されます。これにより、スピン中に当該字句化器・構文解析器を使うようなタスクは実行されない、とされています。

[60] ブロックすると実行されない、という仕組みは十分に説明されていないように思えますが、構文解析を行うタスクがキューに追加されなくなるのでイベント・ループが実行しなくなる、ということでしょうか。既にタスクがタスク・キューに追加されてしまっていれば、それも実行してはいけないのですが、その場合同じタスク・キューを共有する他のタスク源のタスクは同様にブロックされてしまうのでしょうか。

[152] HTML字句化器や XML構文解析器を使うタスクというのは、どうやら実際には、 HTML や XML のファイルを fetch した結果としてバイト列を受信する度に追加されるタスクのことを指しているようです。つまりブロックされている間はそれ以上先に字句化が進まないという規定であるわけです。文書に関連付けられたHTML構文解析器やXML構文解析器が利用されるのは、文書自体の構文解析を除けば、 HTML文書における document.write/document.writeln の呼び出しだけのようです。そちらは定義上、字句化器がブロックされるのと同じ条件下で HTML構文解析器を呼び出さないことになっています。 (なのでいずれにせよ字句化器は止まって先に進みません。)

一時停止

[26] ある条件が満たされるまで利用者エージェントを一時停止 (pause) する場合、次のようにしなければなりません。 >>5

[27] ~~非同期に実行されている算法があって安定状態を待つ状態なら、同期区間を実行してから、 (適切であれば) 非同期算法の実行を再開します。~~
- [199] >>198 により削除されました。
[28] 必要があれば、 Document や閲覧文脈のレンダリングや利用者インターフェイスを更新して現在の状態を反映させます (レンダリングの更新)。
[29] 条件が満たされるまで待ちます。
- [30] イベントループはこの間他のタスクを走らせてはなりませんし、現在走っているタスクもブロックしなければなりません。
- [31] 利用者の入力に対しては反応し続けるべきですが、イベントループが何も実行しないので、低能力で動作するべきです。

[127] 一時停止中のレンダリングについては、モーダルダイアログも参照。

[223] 一時停止中でも動画の再生やアニメーションは続行するべきかもしれません。

[32] 一時停止する算法には次のものがあります。

[33] prompt to unload a document (beforeunload のダイアログ)
[34] ~~obtain the storage mutex (storage mutex 待ち)~~
[35] alert
[36] confirm
[37] prompt
[38] printing steps (印刷)

[220] pause 中は他のタスクを実行できないというのが仕様上の規定ですが、 Firefox ではモーダルダイアログの表示中に Bookmarklet を実行できる (つまり navigate からスクリプト実行のタスクが実行される) ようです。 2015-09-11T11:19:54.000Z

[243] 同じイベントループを共有しているなら、他のタブや窓であっても、タスクは実行できなくなります。

[221] 1つの利用者エージェントが複数のイベントループを使う場合、あるイベントループが一時停止中でも、他のイベントループは動作するかもしれません。

[222] ある起源のスクリプトがモーダルダイアログを表示していても、他の起源の Webページは通常通り表示・操作できるのが好ましいと考えられます。

[237] HTML Standard は、2016年5月以来、Web互換性に悪影響を及ぼさない限りにできるだけこの“異常”な挙動を除去できないか試みることを Webブラウザーの実装者に呼びかけています >>5。

一時中断

[218] ワーカーは、一時中断 (suspend) されることがあります。イベントループの実行も中断されるようです。

ワーカー参照。

[102] 利用者の指示により、またはバッテリーの都合により睡眠状態に入ったなどの理由で、プラットフォームが強制的に Webブラウザーの動作を中断させたり、そこから復帰させたりすることがあります。これを Webブラウザーが検知できるかは、プラットフォーム次第です。しかし検知できるか否かに関わらず、時刻やタイマーの処理などで不整合が生じないように配慮が必要です。

破棄

[108] イベントループは、存在する間動作する HTML Standard (つまり存在しなくなったら停止する) とされています。

[129] 文書環境のイベントループについては、関係する閲覧文脈がすべて破棄された時、ということになると思われます。

[131] ワーカー環境についてはより明確に規定されています。 イベントループのタスクキュー群のタスクがなくなり、 イベントループの WorkerGlobalScope の閉じ中フラグが真の場合 HTML Standard、破棄されます。 (その後ワーカーを走らせる手順の最終段階へと進みます。)

実行時間の報告

[286] イベントループは変数タスク開始時刻により経過時間を保持しています。

[225] イベントループは、イベントループ開始 (event loop begin) とイベントループ終了 (event loop end) を持ちます。 >>5 ともに初期値は null です。

[250] タスク開始時刻とタスクと今についてタスクの時間長を報告するには、次のようにします。 >>5

[251] 最上位閲覧文脈群を、空集合に設定します。
[252] タスクのスクリプト評価環境設定群オブジェクト集合中の各設定群についてそれぞれ、
1. [253] 最上位閲覧文脈群に、 設定群の最上位閲覧文脈を末尾に追加します。
[254] タスク開始時刻、 今、 最上位閲覧文脈群, タスクについて、 report long tasks します。

[255] この手順は、タスクとその直後のマイクロタスクの実行 (>>74) の後に呼び出されます。

[272] 仕様書ではタスクが null でもこれが呼び出されるケースがあります。

[257] イベントループと文書群と今についてレンダリングの更新の時間長を報告するには、次のようにします。 >>5

[259] レンダリング終了時刻を、現在高精度時刻に設定します。
[260] 最上位閲覧文脈群を、 文書群中の文書のうち完全に活性なものすべての最上位閲覧文脈群すべての集合に設定します。
[261] 今, レンダリング終了時刻, 最上位閲覧文脈群について、 report long tasks します。

[258] この手順は、レンダリングの更新の実行後に呼び出されます。

[283] 一時は次のような規定もありましたが、令和元(2019)年の改定で削除されました。 >>280

[234] 利用者エージェントがイベントループを実行しなかった時間長を報告するには、次のようにします。 >>5

[244] イベントループのイベントループ開始を、現在高精度時刻に設定します。
[245] イベントループのイベントループ終了が null でない場合、
1. [246] 最上位閲覧文脈群を、 イベントループに関連付けられた文書すべての最上位閲覧文脈すべての集合に設定します。
2. [247] イベントループのイベントループ開始、 イベントループのイベントループ終了、 最上位閲覧文脈群について、 report long tasks します。

[240] この手順は、イベントループがタスクを実行する直前に呼び出されます。

[284] イベントループを実行しなかった時間とは GC 等に掛かった時間を表していたようです >>280。

構文解析器との関係

[61] HTML の構文解析器 (や、ちゃんと規定した仕様書が存在していませんが、 XML の構文解析器) は、それ自体はタスクの一部や全部ではなく、イベントループとは概念として独立しています。

[62] innerHTML のように完全にタスクに含まれる処理の一部分として構文解析が実行されることもあれば、 fetch によってネットワークからデータを取得する度に順次生成されていく一連のタスクによって断続的に構文解析が進められることもあります。

[149] >>24 や >>59 の通り、構文解析によってイベントループがスピンしたり、字句化器がブロックされたりすることがあります。

スクリプトとの関係

[201] スクリプトは他のスクリプトが実行されていることを直接観測できません >>200。実装上は複数のスクリプトが並列実行されている可能性はありますが (起源が異なる場合やワーカーなど)、そのようなスクリプト同士が通信する方法は postMessage など限られています。

[202] スクリプトの実行時間を計測したり、サーバー側で何らかの情報交換を行ったりして間接的に他のスクリプトの動作を推測することはできるかもしれませんが。

[203] これによって著者はスレッド間のアクセス制御など複雑な処理を書かなくても済みます。 Webブラウザーはスクリプトが同時実行されないことを前提とした最適化を行えます (がそれが制約となるケースもあるかもしれません)。

並列実行との関係

[43] いくつかのアルゴリズムは並列実行されます。すなわち、イベントループの動作中に同時に他のアルゴリズムが実行されていることがあります。

[47] 並列実行されているアルゴリズムとイベントループは、同期区間により “join” されることがあります。

[72] 詳しくは並列実行と安定状態を参照してください。

イベント・ループとの相互作用が不明なもの

[46] HTML 以前に規定されたものや、 HTML 以後であっても明確な仕様が存在しないものは、イベント・ループとどう相互作用するのか文書化されていません。

[45] XSLT の処理とイベント・ループの関係は定義されていません。 >>44

[145] Geolocation API はイベントループが定義される前の仕様書なので関係が説明されていません。おそらく

getCurrentPosition や watchPosition のアルゴリズムは非同期的に実行されます
コールバックはタスクとして追加されます (どのタスクキュー?)
watchPosition は非同期的に実行されているアルゴリズムを停止させます

[67] video や audio の再生の具体的なタイミングは規定されていません。なお track のレンダリングは媒体要素のレンダリングに合わせて更新しなければならないと規定されています。

[197] CODE(XMLe)@en[video]]/audio

[196] aural や speech のレンダリングとの関係は定義されていません。

[20] レンダリングに関わるものは、レンダリングの更新を参照。

原子的に実行されるべきもの

[95] いくつかの算法の一部分は原子的 (atomic) に実行するよう規定されています。

XXX 一覧

実装手法

[79] 仕様書の規定するイベントループを実際にどのような形で実装するべきかは、仕様書の範囲外となっています。他のアルゴリズム同様、著者のスクリプトから観察してブラックボックスとして等しい結果が得られる限り、どのような方法で実装しても問題ありません。

[84] 各イベントループは、それぞれがプラットフォームの別のプロセスとして動作するかもしれませんし、同じプロセスの異なるスレッドで動作するかもしれません。

[82] Webブラウザーは仕様書で規定される処理の他にも、利用者インターフェイスの処理やプラットフォームとのやり取りなど、 Webページの相互運用性には関わらない様々な処理が必要になります。 Webブラウザーの実装手法としての“イベントループ”と、仕様上の (= 著者のスクリプトから見た) イベントループは必ずしも一致しません。

歴史

[4] イベント・ループの概念は Web Applications 1.0 (HTML Living Standard) によってはじめて体系的に説明、仕様化されました。

[87] イベント・ループは最初に Web Workers においてワーカーの挙動を説明するために導入されました。

[88] Web Workers (2013-02-09 03:43:01 +09:00 版) http://web.archive.org/web/20080828221023/http://www.whatwg.org/specs/web-workers/current-work/#queue

[89] 更にその後、メイン・スレッドについてもイベント・ループが定義されるようになりました。タスクの概念もこの時導入されました。

...

[2] Web Applications 1.0 r6966 Allow browsers to bail early for showModalDialog, alert, confirm, and prompt during pagehide, beforeunload, and unload events. ( (2012-02-07 07:54:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=6965&to=6966

[86] ワーカーのイベント・ループはメインのイベント・ループと同じように処理されますが、 >>87、>>89 という経緯からか当初は run a worker 算法に組み込まれており、閉じ中 (closing) フラグの存在など微妙に定義が違っていました。しかし >>85 によって両者の定義が統合されました。