Summary

  • W3Cは2009年4月23日にWeb Workersの最初の作業草案を公開した。ページは別の並列実行環境でスクリプトを始め、メッセージをやり取りできる。
  • 草案の素数の例では、workerが計算を続け、新しく見つけた数をページへ送る。ページは表示を更新しながらクリックなどの操作を受け付ける。

「計算する」を押す。数字はしばらく変わらない。もう一度押す。ボタンは画面にあるのに返事がない。やっと動いたと思ったら、たまっていた操作がまとめて現れる。利用者から見れば、店員が窓口で「少々お待ちを」と言う間もなく、奥の倉庫へ走っていったようなものだ。仕事をしているのは分かる。戻ってくる時刻は分からない。

W3Cが2009年4月23日に出したWeb Workersの最初の作業草案は、この窓口の問題を正面から扱った。クリックなどに応じるスクリプトとは独立して、長い仕事を背景で実行するAPIを定めた。説明に選んだのは素数探しである。主文書がworkerを起動し、workerが次の素数を見つけて送り、ページが最新の数を表示する。算数は奥で続き、窓口は客の声を聞ける。

仕組みは役割分担ではっきりする。ページはスクリプトのURLを渡してWorkerを作る。ブラウザーはそれを別の並列実行環境で動かす。両者はpostMessageと受信側の処理で情報を交換する。workerは計算し、ページは表示する。新しい素数を発見しても、workerが直接画面の数字を書き換えるのではなく、結果を届けた後でページの処理が見える文字を変える。裏方には成果を伝える出口が必要だった。

2009年12月の後続草案は、メッセージの受け渡しで調整する、スレッドに似た動作としてこの方式を説明した。途中に郵便口があるからこそ、ページは到着した答えをどう扱うか決められる。利用者が別の計算を始めた後で古い結果が届いたら、それを表示するかどうか判断する場所はページ側にある。頑張って計算したことと、いま読者に見せるべきことは別の仕事だ。

素数の例には余計な登場人物がいない。遠くのサーバーも遅い回線も関係ない。ページが鈍くなる理由は、同じところで長い計算を続けているからだ。ループをworkerへ移し、見つけた数をメッセージで返す。画面は届いた分だけ更新でき、クリックへの応答も続けられる。「処理中」の表示だけ立派にして黙り込むより、ずっと正直な接客である。

裏方を増やすにも費用がかかる。2009年12月草案は、workerの起動や個々のメモリー使用を軽く見てはいけないと述べた。四百万画素の画像で一画素ごとにworkerを作る、という笑える例も載せている。四百万人の助手を呼んでから全員に机を探す羽目になる。意味のあるまとまりを任せるから、並列の作業場が役に立つ。

文書が進むと、助手の種類も整理された。2012年の候補勧告スナップショットには、作成元とやり取りする専用workerと、同一オリジンの複数の相手につながる共有workerがある。2015年の作業草案は、Workerの作成、onmessage、postMessage、共有workerで使う明示的なMessagePortを詳しく記した。別の部屋で働くなら、返事を届ける相手と経路を決めなくてはならない。

この境界は計算の場所を決める。ブラウザー内の保存領域が「データはどのウィンドウ、どのオリジンに属するか」を問うのに対し、workerは「長い仕事をどこで進め、どう結果を返すか」を扱う。同じページに両方あってもよい。利用者が選んだ条件を保持し、重い検索を背景へ送り、答えを画面で受け取る。仕事の場所と読者への応答を分ければ、画面は一つの長い列に閉じ込められない。

W3Cの公開履歴は2009年の草案から2012年、2015年の段階を記録している。最初の素数探しは今も分かりやすい。ページが賢く計算している間も、こちらのクリックを聞いているか。workerを奥へ送り、メッセージを窓口へ戻す設計は、その問いへの具体的な返事だった。