naloveyuki/BitLogger
1
0
Fork 0
mirror of https://github.com/Nanaloveyuki/BitLogger.git synced 2026-07-24 00:42:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

📝 clarify async worker capability probe

Browse Source
This commit is contained in:
Nanaloveyuki
2026-06-14 10:17:05 +08:00
parent 754a878cd8
commit 8cf4eba223
1 changed files with 3 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/async-runtime-supports-background-worker.md
+3
View File
@@ -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