探索メモ: ブラウザーの中で、2 つの wasm-gc の Wasm をつなぐ #

1. JS が仲介する #

const parser = await load("parser");
const html = await load("html");
html.render(parser.parse(md));

make try で、parse が返した JSON と、render がそれから作った HTML を見た。入れ子のリスト、コード、リンクも、エスケープも、前の探索の render と同じ形になった。

2. Wasm から別の Wasm の関数を直接呼ぶ #

const linked = await load("linked", { html: { render: html.render } });
linked.preview(md);

WebAssembly.Module.imports で見た linked.wasm の import は、[{"module":"html","name":"render","kind":"function"}] の 1 つだけ。そこに html.wasm の export（Wasm の関数）を JS の関数で包まずに渡した。linked.preview(md) は、1 の html.render(parser.parse(md)) と同じ文字列を返した（Node と Chrome）。

エンジンがこの呼び出しを Wasm から Wasm への直接の呼び出しにしているか（JS を経由する層があるか）は、確かめていない。

3. Worker を分けて、メッセージでつなぐ #

ページは Worker を 2 つ作り、MessageChannel の両端を 1 つずつ渡す。

page --(md)--> parser Worker --(json, MessagePort)--> html Worker --(html)--> page

• parser-worker.mjs: ページから { id, md } を受け、parse した JSON を { id, json } としてポートに送る。
• html-worker.mjs: ポートから { id, json } を受け、render した HTML を { id, html } としてページに送る。
• ページは id ごとに Promise を待つ。入力が速いときは、最後の入力の結果だけを表示する。

JSON はページを通らず、Worker の間で直接渡る。「ブラウザーの中で parser と html のサービスが動いている」形になる。

**Worker を書くときの落とし穴**: 最初は Worker の中で const { parse } = await load("parser") としてから onmessage を設定していた。これだと、ページが先に送ったポートのメッセージが失われる。html が undefined のまま、TypeError: Cannot read properties of undefined (reading 'postMessage') になった。トップレベルの await が終わるまでハンドラーがないので、その間に届いたメッセージは誰にも受け取られない。ハンドラーを先に設定し、その中で読み込みの Promise を待つようにして直した。

4. 重い処理でページが固まるか #

/?check は、サンプルの Markdown を 20,000 回つないだもの（2,100,000 UTF-16 コード単位）を、3 つの形に 1 回ずつ通す。測るのは次の 2 つ。

• 結果が返るまでの時間
• その間、10 ms ごとのタイマーの間隔がいちばん開いたところ。これがページのスレッドが止まっていた時間になる。

先に 1 回ずつ通して温めてある。make check-browser を 4 回動かした結果は次のとおり。

1 と 2 は、処理している間ずっとページが止まる。この間は入力も描画もできない。3 は全体で 30〜60 ms 長いが、ページのスレッドはタイマーの間隔どおりに動き続けた。--virtual-time-budget を付けた headless の Chrome は仮想の時間で動き、タイマーの間隔が実際とずれるので、計測には使わなかった。

1 と 2 の差は、測った範囲では見分けられなかった。2 で JS を挟まなくなっても、呼ぶのは文書ごとに 1 回なので、時間のほとんどはパースと HTML を作ることにかかる。