Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Embedders cannot offer async handlers: microtasks never drain while the host owns the thread (and library mode refuses async)

オープン
  • 何か問題がありますか？
#265 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
42/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
compilers

調査の方向性

まず、実行可能レーンの保持されたコールバックの再入と、ライブラリモードの async_free 検証を追跡し、次に既存の promise またはマイクロタスクキューと prefix_reset エクスポートを特定します。両方のレーンでホストから呼び出し可能な drain がどのように動作するか、ライブラリグラフで非同期関数がどのように許可されるようになるかを定義し、タイマー、スレッド、シグナルハンドラー、イベントループが導入されないことを確認します。

索引モデルが issue の本文から書いたものです。

説明

Embedders currently cannot let user code write async handlers, because promise continuations never run while the host owns the main thread. This is a narrower request than #260 (which I closed as unusable for us) — it asks for microtask draining only, and explicitly does not ask scriptc to own a clock, threads, or an event loop.

Version: scriptc 0.0.35, macOS 26.5 arm64.

The two halves

Executable lane — the queue exists but is never serviced during the app's life. A host that owns the loop re-enters the program through a retained callback; a continuation scheduled during one entry has still not run at the next entry:

let flag = "not-run";
// invoked from the host, entry #1
Promise.resolve().then(() => { flag = "MICROTASK RAN"; });
return "scheduled, flag=" + flag;
// invoked from the host, entry #2 — a separate call
return "flag=" + flag;

1st: scheduled, flag=not-run
2nd (separate re-entry): flag=not-run

The continuation only runs once the program's main body returns, which for an embedded app means "at exit".

Library mode — async is refused outright, even with no timers anywhere in the graph:

async function slowAdd(a: number): Promise<number> { return a + 1; }

SC4005: library mode requires an async_free module graph, and this graph reaches an async function ('slowAdd')

What would unblock it

A host-callable microtask drain — "run pending promise continuations, then return":

  • in the executable lane, callable from a host that owns the main thread;
  • in library mode, an exported <prefix>_drain (alongside <prefix>_reset), together with permitting async functions in the graph.

Microtasks are not timers. Library mode's stated contract — "v1 library artifacts link no event loop, install no signal handlers, and create no threads" — is preserved exactly: draining a queue needs no clock, no threads and no signal handlers. The host keeps ownership of time; it just gets a way to say "now run what's ready".

Why this is worth it (and why it differs from #260)

I closed #260 because it asked for a general loop pump, and we could not consume it: our framework has to work in library mode too, where there is no loop to pump. This ask is consumable in both lanes precisely because it doesn't involve the loop.

Concretely, it is the difference between an embedder's users writing this:

app.commandAsync("load", (args, resolve) => {
  app.readFileAsync(args.path, (err, text) => resolve(transform(text)));
});

and this:

app.command("load", async (args) => {
  const text = await app.readFile(args.path);
  return transform(text);
});

The second is what a TypeScript developer expects to write. The host can already resolve the promise — in our design the shell owns the timers and file I/O and calls back into the compiled code — so the only missing piece is a point at which continuations are allowed to run.

Context

janela — a Tauri-style desktop framework, TypeScript backend compiled by scriptc, OS webview for the window, no JS engine bundled. It now runs on macOS, Linux, Windows, and on iOS via library mode. Async works today through explicit callbacks (commandAsync(name, (args, resolve) => …)), with the host owning a due-ordered timer queue and re-entering the compiled code when work is due — so we are not blocked. But we cannot offer idiomatic async/await to our users on either lane, and the failure mode on the executable lane is unkind: an async handler compiles, looks correct, and silently never resolves.

Happy to test a prototype against both lanes if that would help.

主要言語
TypeScript
スター
5.1k
フォーク
130
平均マージ
1時間 13分
マージ済み PR（30日）
254

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

vercel-labs/scriptc のほかの issue

vercel-labs/scriptc の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。