From 8cf4eba223418e4906e1d4665d9b2fe8257a53e2 Mon Sep 17 00:00:00 2001 From: Nanaloveyuki Date: Sun, 14 Jun 2026 10:17:05 +0800 Subject: [PATCH] :memo: clarify async worker capability probe --- docs/api/async-runtime-supports-background-worker.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/api/async-runtime-supports-background-worker.md b/docs/api/async-runtime-supports-background-worker.md index 0945397..26eb78c 100644 --- a/docs/api/async-runtime-supports-background-worker.md +++ b/docs/api/async-runtime-supports-background-worker.md @@ -36,6 +36,7 @@ Detailed rules explaining key parameters and behaviors - `true` indicates native worker capability. - `false` indicates compatibility-mode behavior. - This helper is derived from backend-specific async runtime implementation choice. +- The boolean is read from the active backend helper on each call rather than from a cached runtime snapshot object. - In the current backend split, the native implementation returns `true` while the compatibility stub returns `false`, matching the same mode pair exposed through `async_runtime_mode()` and `async_runtime_state()`. - The async library still targets multiple backends even when this helper returns `false`. - Use it when an enum branch is unnecessary and a boolean capability check is enough. @@ -69,6 +70,8 @@ In this example, a simple boolean can drive compact status output. e.g.: - This API does not normally fail at runtime; it reflects compiled backend behavior. +- If callers need the current paired mode and worker flag together, prefer a fresh `async_runtime_state()` call instead of mixing this boolean with an older saved mode value. + - If you need the exact mode name rather than a boolean, use `async_runtime_mode()` or `async_runtime_state()`. ### Notes