std/asyncdispatch and std/threadpool: Awaiting a FlowVar Without Stalling the Event Loop

I am designing a Nim service where async request handlers (std/asyncdispatch) occasionally need to call a legacy blocking library. The documented escape hatch is std/threadpool's spawn, which returns a FlowVar[T], but a FlowVar cannot be awaited natively inside an async procedure. The options appear to be polling isReady in a loop with sleepAsync, blocking on the FlowVar (which would serialize the event loop), or writing a custom bridge.

Constraints: spawn deep-copies its arguments and requires GC-safe, side-effect-disciplined parameters, so shared mutable state must cross the boundary via channels or locks. Behavior also seems to depend on the memory model (--mm:orc default in Nim 2.x versus --mm:refc) and --threads:on, and I have not found an officially blessed async-to-thread adapter in the standard library. Assume Nim 2.x with asyncdispatch and threadpool; exact version details should be verified against local docs.

Is there a standard or recommended pattern for awaiting a FlowVar inside an async proc without blocking the dispatcher? How should the memory model choice influence the design of data passing across this boundary? When polling isReady, what sleep interval strategy avoids both latency and busy-waiting?