BitLogger/docs/api/async-runtime-supports-background-worker.md

name, group, category, update-time, description, key-word

name	group	category	update-time	description	key-word
async-runtime-supports-background-worker	api	async	20260512	Return whether the current backend provides native async background worker support.	async runtime worker public

Async-runtime-supports-background-worker

Return a boolean telling callers whether the current backend provides native background worker semantics for bitlogger_async. This is the narrowest capability probe when only worker support matters.

Interface

pub fn async_runtime_supports_background_worker() -> Bool {}

input

• none - No explicit arguments are required.

output

• Bool - true when native background worker semantics are available, otherwise false.

Explanation

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.
• 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.

How to Use

Here are some specific examples provided.

When Need A Simple Capability Branch

When logic only depends on worker availability:

if async_runtime_supports_background_worker() {
  println("native worker available")
}

In this example, callers avoid a more verbose mode match.

When Add Diagnostics Labels

When capability should be surfaced in diagnostics:

println(if async_runtime_supports_background_worker() { "worker" } else { "compat" })

In this example, a simple boolean can drive compact status output.

Error Case

e.g.:

• This API does not normally fail at runtime; it reflects compiled backend behavior.

• If you need the exact mode name rather than a boolean, use async_runtime_mode() or async_runtime_state().

Notes

1. Use this helper for minimal capability checks.

2. Prefer async_runtime_state() when you want the same information in a richer object.

3. A false result should be read as "compatibility-mode runtime behavior" rather than "async library unsupported on this target".

4. This helper does not by itself imply that every non-worker backend has been equally re-verified for the current release; see target-verification.md.