Skip to main content

pre_map_pending_uses

Function pre_map_pending_uses 

Source
pub fn pre_map_pending_uses(
    pool: &Arc<ResourcePool>,
    tree: &SceneTree,
    phases: &HashMap<String, WorkloadPhase>,
    default_driver: &str,
    merged_params: &HashMap<String, String>,
) -> Result<(), String>
Expand description

Walk the freshly-pre-mapped scenario tree and seed the pool’s pending_uses counter for every phase that will attach a pool-shareable adapter. Called once at session bootstrap, after [crate::executor::pre_map_tree] returns and before the executor begins running any phase.

For each phase node:

  1. Determine the adapter name — phase.adapter override (when the phase declares one) wins over the session-level default_driver.
  2. Resolve the driver name without instantiating anything (resolve_driver_name).
  3. Look up the matching SharedDriverRegistration. If none registered, the phase rides the legacy PerPhase path — its key is per-phase-unique, so pre-map contributes zero to any shared pending_uses and the legacy close-on-detach path handles teardown.
  4. Compute the resource key from the session’s merged_params via the registration’s pure resource_key function. resource_key failures are hard errors at session bootstrap — surfacing the same misconfiguration that attach_shared_adapter would have hit at runtime, just earlier and in one place.
  5. Increment the per-key pending_uses counter via ResourcePool::declare_pending_use.

This is a pure read of the scenario tree + phase params; no adapters are instantiated. The walker can run before pool.shutdown() would otherwise be a no-op — and must run before the first phase, since pending counts are the close trigger that releases shared resources promptly when their last user finishes.