Skip to content

Async-runtime-state

Read the current backend-specific async runtime state for diagnostics. This API focuses on the environment-level async mode rather than any one logger instance.

Interface

moonbit
pub fn async_runtime_state() -> AsyncRuntimeState {}

input

  • none - This API reads the current backend mode and does not require logger input.

output

  • AsyncRuntimeState - Runtime snapshot containing mode and background_worker capability.

Explanation

Detailed rules explaining key parameters and behaviors

  • mode is derived from the active backend implementation.
  • background_worker tells callers whether native worker semantics are available.
  • This helper is equivalent to AsyncRuntimeState::new(async_runtime_mode(), async_runtime_supports_background_worker()).
  • The returned pair is rebuilt from those two lower-level helpers on each call rather than read from a cached runtime object.
  • In the current backend implementations, the resulting pair is NativeWorker + true or Compatibility + false.
  • async_runtime_state_to_json(...) and stringify_async_runtime_state(...) serialize this state.
  • This API is environment-scoped and does not depend on a particular AsyncLogger instance.
  • The returned value is a snapshot data object, not a live runtime handle, so later backend checks require calling async_runtime_state() again rather than reusing an older value as if it refreshed itself.

How to Use

Here are some specific examples provided.

When Need Startup Diagnostics

When startup logs should reveal async backend behavior:

moonbit
println(stringify_async_runtime_state(async_runtime_state(), pretty=true))

In this example, backend mode is exposed before any logger is started.

When Branch Behavior By Runtime Capability

When code should react differently depending on worker support:

moonbit
let runtime = async_runtime_state()
if runtime.background_worker {
  println("native worker path")
}

In this example, branch decisions are based on actual runtime capability instead of assumptions.

Error Case

e.g.:

  • This API does not normally expose a dynamic error path; it reports the currently compiled backend behavior.

  • The returned AsyncRuntimeState value is not cached onto the helper. If callers need a newer backend read, they must call async_runtime_state() again instead of expecting an older value to refresh itself.

  • If callers need richer runtime state, they should use AsyncLogger::state() on a logger instance instead.

Notes

  1. Use this API for environment-level diagnostics.

  2. Use AsyncLogger::state() for logger-instance diagnostics.

  3. Use AsyncRuntimeState::new(...) only when code or tests need to construct a manual snapshot instead of probing the current backend.

Published from the repository docs folder with VitePress.