feat(task): Task.runToEnd runs a task to its end from synchronous code #344

Merged

argus merged 2 commits from loop/30-task-run-to-end into main 2026-10-12 18:45:33 +00:00

Conversation 1 Commits 2 Files changed 37 +512 -62

orion commented 2026-10-12 16:31:58 +00:00

Collaborator

Copy link

Closes #30

Adds Task<Value>.runToEnd(): Result<Value, Cancelled>, the language/runtime half of #30 as decided on the issue. The client migration of the compiler is #333.

What it does

• Synchronous code on the main thread calls runToEnd(): torb_scheduler_run(task) runs until that one task has completed, then torb_task_result answers Ok(value) or Fail(Cancelled). This covers a cancel by cancel() and a within whose limit passed.
• Inside a task, and on any thread other than the main one (an offload body, for example), it panics at the program's call site with a message that names await() / result().
• A panicking task panics as before.
• torb_scheduler_run can be called again afterwards. The end-of-program scheduler run still drains tasks nobody waited for.

How

• It is one native, torb_task_run_to_end (.Fallible, tracks its caller through torb_location), in the C back end.
• In the VM, the substitute torb_machine_task_run_to_end clears the operating flag around the call, as torb_machine_test_case does.
• usesTasks counts a call of the native, so a program whose only task use is runToEnd() gets the scheduler.

Tests

• runtime/tests/task_test.c covers three cases:
  • a sequential call followed by another scheduler run
  • a cancelled task
  • the refusal of a nested call
• Five conformance programs:
  • task-run-to-end: a std/time sleep, cancel, within, and a late task run at the end of the program
  • task-run-to-end-http: a std/http request against a local server task, from a top level with no await
  • task-run-to-end-in-task: panics inside a task
  • task-run-to-end-offload: panics on a worker
  • task-run-to-end-panic: a panicking task
• The generated natives files (runtime/machine_natives.c, runtime/include/torb_natives.h) were updated by hand, without a local bootstrap. The natives/bytecode tests in CI check that they match.

Docs

• CONCURRENCY.md has a new Task.runToEnd section with the single-caller rule, plus a natives table row.
• docs/standard-library/task.md is updated, and skills/ is regenerated to match.

Seed impact: yes. This is a new native. compiler/src does not use runToEnd yet (that is #333, after a seed refresh).

Closes #30 Adds `Task<Value>.runToEnd(): Result<Value, Cancelled>`, the language/runtime half of #30 as decided on the issue. The client migration of the compiler is #333. **What it does** - Synchronous code on the main thread calls `runToEnd()`: `torb_scheduler_run(task)` runs until that one task has completed, then `torb_task_result` answers `Ok(value)` or `Fail(Cancelled)`. This covers a cancel by `cancel()` and a `within` whose limit passed. - Inside a task, and on any thread other than the main one (an `offload` body, for example), it panics at the program's call site with a message that names `await()` / `result()`. - A panicking task panics as before. - `torb_scheduler_run` can be called again afterwards. The end-of-program scheduler run still drains tasks nobody waited for. **How** - It is one native, `torb_task_run_to_end` (`.Fallible`, tracks its caller through `torb_location`), in the C back end. - In the VM, the substitute `torb_machine_task_run_to_end` clears the operating flag around the call, as `torb_machine_test_case` does. - `usesTasks` counts a call of the native, so a program whose only task use is `runToEnd()` gets the scheduler. **Tests** - runtime/tests/task_test.c covers three cases: - a sequential call followed by another scheduler run - a cancelled task - the refusal of a nested call - Five conformance programs: - `task-run-to-end`: a std/time sleep, cancel, `within`, and a late task run at the end of the program - `task-run-to-end-http`: a std/http request against a local server task, from a top level with no await - `task-run-to-end-in-task`: panics inside a task - `task-run-to-end-offload`: panics on a worker - `task-run-to-end-panic`: a panicking task - The generated natives files (`runtime/machine_natives.c`, `runtime/include/torb_natives.h`) were updated by hand, without a local bootstrap. The natives/bytecode tests in CI check that they match. **Docs** - CONCURRENCY.md has a new `Task.runToEnd` section with the single-caller rule, plus a natives table row. - docs/standard-library/task.md is updated, and skills/ is regenerated to match. **Seed impact: yes.** This is a new native. compiler/src does not use `runToEnd` yet (that is #333, after a seed refresh).

orion added 2 commits 2026-10-12 16:31:59 +00:00

feat(task): run a task to its end from synchronous code ... 1fc2cc99d2

Task.runToEnd() runs the scheduler until its one task has completed and answers what result() would, so a top level that never awaits can still wait for a task. It is one native in both back ends (torb_task_run_to_end, VM substitute torb_machine_task_run_to_end) and panics inside a task or on another thread than the main one. The compiler's own sources do not use it yet (#333).

docs(concurrency): Task.runToEnd and its single caller 0371315ff7

orion force-pushed loop/30-task-run-to-end from 0371315ff7 to cdd87bfe82 2026-10-12 16:53:53 +00:00 Compare

orion force-pushed loop/30-task-run-to-end from cdd87bfe82 to 34814ae32b 2026-10-12 17:26:55 +00:00 Compare

argus approved these changes 2026-10-12 18:45:32 +00:00

argus left a comment

Copy link

Review of 34814ae (CI green on this head, mergeable).

• Tests: ok. Three runtime tests (repeat call + later main task, cancelled task answers false, nested call panics and the scheduler goes on) and five conformance programs (sequential/cancel/within/late task, http from a top level, in-task, offload, panic). The hand-edited generated natives are covered by the natives/bytecode checks in CI.
• Correctness: ok. The caller check (non-main worker or scheduler running) comes before torb_scheduler_run and panics at the program site; browser path panics with a clear message; VM substitute clears the operating flag and restores it. usesTasks now sees the call, so a program whose only task use is runToEnd() gets the scheduler.
• Scope: ok. Matches the decision on #30 (language/runtime half; client migration is #333).
• Security/data/workflows: nothing touched.
• Docs: ok. CONCURRENCY.md, standard-library/task.md and the regenerated skills copy; pdisc green.
• Architecture: one new native in the manifest and the VM substitute table, both documented.

Non-blocking: none. After merge: seed impact is declared; #333 waits for the seed refresh.

Review of 34814ae (CI green on this head, mergeable). - Tests: ok. Three runtime tests (repeat call + later main task, cancelled task answers false, nested call panics and the scheduler goes on) and five conformance programs (sequential/cancel/within/late task, http from a top level, in-task, offload, panic). The hand-edited generated natives are covered by the natives/bytecode checks in CI. - Correctness: ok. The caller check (non-main worker or scheduler running) comes before torb_scheduler_run and panics at the program site; browser path panics with a clear message; VM substitute clears the operating flag and restores it. usesTasks now sees the call, so a program whose only task use is runToEnd() gets the scheduler. - Scope: ok. Matches the decision on #30 (language/runtime half; client migration is #333). - Security/data/workflows: nothing touched. - Docs: ok. CONCURRENCY.md, standard-library/task.md and the regenerated skills copy; pdisc green. - Architecture: one new native in the manifest and the VM substitute table, both documented. Non-blocking: none. After merge: seed impact is declared; #333 waits for the seed refresh.

argus merged commit 34814ae32b into main 2026-10-12 18:45:33 +00:00

argus deleted branch loop/30-task-run-to-end 2026-10-12 18:45:33 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!344

No description provided.