From d7e92d588f9eaf690fc1f6210a3e4643e7284f77 Mon Sep 17 00:00:00 2001 From: yyc12345 Date: Fri, 14 Aug 2026 13:37:41 +0800 Subject: [PATCH] doc: update omrf docstring --- omrf/src/library_lifecycle.rs | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/omrf/src/library_lifecycle.rs b/omrf/src/library_lifecycle.rs index 13f69a7..7a6515e 100644 --- a/omrf/src/library_lifecycle.rs +++ b/omrf/src/library_lifecycle.rs @@ -14,10 +14,16 @@ //! //! # Typical usage //! -//! A single instance is usually stored in a `static LazyLock` and shared across all FFI entry -//! points. The state `S` typically aggregates the library's DLL-level resources -- for example a -//! number of [`ObjectPool`](crate::object_pool::ObjectPool)s and other globals that must be -//! constructed on first startup and torn down on last shutdown. +//! A single [`LibraryLifecycle`] instance is usually stored in a `static LazyLock` and shared +//! across all FFI entry points. The state `S` aggregates the library's DLL-level resources -- for +//! example a number of [`ObjectPool`](crate::object_pool::ObjectPool)s and other globals. +//! +//! Reach for [`LibraryLifecycle`] only when acquiring those resources **can fail** and you want to +//! surface that failure to the caller explicitly through the `startup` / `shutdown` functions. When +//! resource construction is infallible (or its failure need not be reported), a plain +//! `static LazyLock` is sufficient -- it lazily initializes `S` as the DLL loads, with no +//! lifecycle machinery required. Collecting the library's state into a single `S` struct is +//! recommended either way. //! //! # Call order //!