worker.terminate() is a no-op during entry evaluation, and terminating there wedges teardown
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript
- 领域
- backend
调研方向
从 WorkerWrapper.mm 中的 Terminate 实现及其注释开始,然后将 iOS 的行为与 Android 的 e11c9c30 和 351bef64 更改进行比较。跟踪 entry 评估、被泵送的模块图、TLA 停驻、settle-gate 评估、拆除,以及异常/消息格式化。完成的标准是:所述的六条 termination 规则在两个平台上都成立,并且重复运行的 spec 测试能在泵送过程中终止一个停驻的 .mjs entry。
由索引模型根据 Issue 内容生成。
描述
Found while completing #443's pump-termination item (three empirical rounds on the #444 branch); target semantics below are verified on Android, where terminate-during-entry works (android#2021 @ 351bef64, spec-proven with terminate landing 0-1ms into the entry body).
The defect (iOS)
The no-op: WorkerWrapper::workerIsolate_ is assigned only after the background looper's func() returns — and func() is where entry evaluation (the pumped module-graph load, any top-level-await park) runs. Terminate() bails on the null isolate, so for a worker still inside its entry, worker.terminate() does nothing: no TerminateExecution, no termination-requested flag. The pump bails landed in #444 engage only once the worker has a published isolate — the parked-entry scenario #443's pump item describes is unreachable on iOS for this reason.
The wedge: publishing the isolate early (via a separate atomic, drain-guard semantics untouched) makes Terminate() genuinely fire mid-entry — and the suite then hangs past 600s in teardown. That attempt was reverted on #444's branch: shipping it would convert a silent no-op into a hang. The comment at WorkerWrapper.mm (Terminate) records the gap at the site.
Target semantics — what correct terminate-during-entry looks like
Verified end-to-end on Android (trace + spec); the fix here must satisfy all six:
- Prompt pump exit via a termination-requested flag, not the V8 probe alone —
IsExecutionTerminatingis a mid-unwind probe and a parked pump runs no JS. (Already converged: android e11c9c30 / iOS's requested-flag in #444; iOS's flag is currently unreachable mid-entry because of the no-op above.) - Termination never masquerades: the evaluator checks termination BEFORE its timeout branch (never "Top-level await timed out"), and exception construction has an explicit HasTerminated/empty-Message branch (never an entry rejection with a fabricated message).
- No onerror on a dying worker: the error router early-returns on the wrapper's terminating flag — a terminated entry produces neither worker-scope
onerrornor a parent error event. Terminate is not an error. - Everything after the bail runs no JS and tolerates empty answers: the settle-gate's capability re-
Evaluate()returns empty on a terminating isolate and must fall through inertly; the teardown chain drops loop entries and releases handles only, never consuming an unchecked Maybe beforeDispose. - Error-report building must be termination-safe: anything between the bail and disposal that formats messages/stacks must read through
FromMaybe/IsEmpty, neverToChecked/ToLocalChecked— the termination interrupt can materialize inside the reporter itself (ToDetailStringruns JS). Android hit exactly this CHECK-abort and fixed it in 351bef64; iOS's exception/message formatters need the same audit as part of this work. - The window is real, not theoretical: on Android the spec's terminate landed 0-1ms into the entry body on every iteration. Any fix must be spec-proven with the same shape (worker .mjs entry parked in TLA, terminated mid-pump, repeated iterations).
Scope
A worker-lifecycle design pass: early isolate publication paired with a teardown path that tolerates termination landing inside entry evaluation (the pumped graph load, the TLA park, and the queue-arm-before-isolate window are all live during func()), plus the rule-5 formatter audit. Cross-runtime contract: the six rules above should hold identically on both platforms; Android already conforms.
- 主要语言
- JavaScript
- 星标
- 150
- 派生
- 43
- 平均合并
- 3 天 10 小时
- 30 天内合并 PR
- 22
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
NativeScript/ios 的其他 Issue
-
难度 5/5 一周以上 新手友好度 38/100
NativeScript/ios#459 · 1 条评论 ·
-
难度 3/5 3-5 天 新手友好度 66/100
NativeScript/ios#414 ·
-
question
难度 4/5 3-5 天 新手友好度 34/100
NativeScript/ios#364 · 2 条评论 ·
-
难度 4/5 3-5 天 新手友好度 35/100
NativeScript/ios#355 ·
-
难度 4/5 3-5 天 新手友好度 25/100
NativeScript/ios#292 · 9 条评论 ·
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
palladius/rails8-app-on-gcp#145 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
dotenvx/dotenv-vscode#139 ·
-
test-change-proposal
难度 2/5 1-3 小时 新手友好度 65/100
web-platform-tests/interop#1455 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
corsairdev/corsair#1764 ·
-
难度 2/5 1-3 小时 新手友好度 75/100