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

Direct answer

As of Nim 2.x there is no officially blessed standard-library adapter that turns a FlowVar[T] into an awaitable Future[T]. std/asyncdispatch and std/threadpool are separate worlds: the dispatcher schedules Futures on one thread, while spawn runs work on pool threads and hands back a FlowVar whose only completion APIs are the blocking get()/sync() and the non-blocking isReady. So the practical, honest answer is: write a small polling bridge yourself. It is a few lines, it is the pattern most Nim services use, and it keeps the event loop free.

The recommended pattern: a polling bridge

Wrap the FlowVar in an async proc that checks isReady and yields to the dispatcher with sleepAsync between checks:

import std/[asyncdispatch, threadpool, times]

proc awaitFlowVar[T](fv: FlowVar[T], intervalMs: int = 10): Future[T] {.async.} =
  while not fv.isReady:
    await sleepAsync(intervalMs)
  return ^fv   # or fv.sync(); blocks only after isReady is true

proc handleRequest(x: int) {.async.} =
  let fv = spawn legacyWork(x)
  let result = await awaitFlowVar(fv)
  echo result

Because sleepAsync returns control to the dispatcher, other request handlers keep running while the pool thread executes the legacy call. Never call fv.get() or ^fv before isReady is true — that blocks the dispatcher thread and serializes your entire service.

One caution: this code is written against documented Nim 2.x APIs, but I have not compiled it here. Verify against your local nim doc output, since exact signatures (e.g., the ^ operator on FlowVar) should be confirmed for your compiler version.

Choosing the sleep interval

The trade-off is simple: shorter intervals reduce added latency, longer intervals reduce wasted wake-ups. In practice:

• 10–20 ms is a reasonable default for I/O-bound legacy calls lasting hundreds of milliseconds or more. The added latency is at most one interval on average half an interval, which is negligible relative to the call itself.
• Avoid intervals under ~5 ms; at that point you are effectively busy-waiting with extra steps, and each wake-up costs a timer and a dispatcher cycle.
• If your blocking calls have a known typical duration n, a fixed interval around max(10, n div 4) ms bounds the overhead while keeping wake-ups few.
• An adaptive backoff (start at 2–5 ms, double up to a 50 ms cap) is a modest improvement when call durations vary widely, but a fixed 10 ms is simpler and usually sufficient.

Memory model and data passing

Nim 2.x defaults to --mm:orc; --mm:refc is the older alternative. Either way, --threads:on is required for threadpool. The memory model matters less than the discipline at the boundary:

• spawn requires GC-safe expressions and deep-copies its arguments into the worker. Treat everything you pass as immutable input; do not share mutable objects between the async thread and the pool thread.
• Return results through the FlowVar itself (value semantics, copied back), not through captured globals or shared references.
• If you genuinely need streaming or bidirectional communication with the worker, use std/channels or explicit locks rather than shared mutable state — under orc, unsynchronized shared mutation is a data race, not a managed situation.
• Because of the deep copy, avoid passing large structures into spawn; pass a compact descriptor (path, ID, offset range) and let the worker load what it needs.

Verification

nim c --threads:on --mm:orc -r your_service.nim

To confirm the loop stays responsive, run two concurrent handlers — one awaiting a slow spawn, one answering immediately — and check that the fast handler's latency is unaffected. If you use the polling bridge, watch CPU with top; a healthy bridge idles near zero between wake-ups.

Uncertainty

This answer reflects documented Nim 2.x behavior as of my knowledge; the standard library evolves, so check whether your Nim version has added an official async/threadpool bridge before adopting the polling wrapper. One detail that would refine this advice: the typical duration of your blocking calls, since that drives the ideal polling interval.