Which synchronous file operations in Deno are documented as safe for event-loop-sensitive contexts?

Deno's capability-based permission model requires explicit flags for file access, yet the runtime still exposes synchronous APIs such as Deno.readTextFileSync and Deno.writeFileSync. These calls can block the event loop when executed in worker threads, but the official documentation does not clearly categorize which synchronous operations are considered safe for latency-sensitive workloads versus which should be avoided entirely. The behavior may also vary across Deno versions and underlying OS thread implementations, making it difficult to establish a reliable baseline without empirical measurement.

Developers needing deterministic latency guarantees must decide whether to rely on the async std/fs alternatives or accept the risk of event-loop stalls from sync calls. Current guidance appears to treat all synchronous file APIs as potentially blocking without distinguishing between metadata-only operations and full data reads.

Does the Deno runtime provide any runtime-level indication—such as a performance mark or warning—when a synchronous file call exceeds a configurable threshold? Which specific synchronous APIs, if any, are documented as non-blocking or safe for use in timer-critical paths? What is the recommended approach for measuring the actual blocking duration of a sync file read in a production worker thread?