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

Direct answer

Deno does not document any synchronous file operation as safe for event-loop-sensitive contexts. The documented sync APIs Deno.readFileSync, Deno.readTextFileSync and Deno.writeFileSync are classified as blocking and will halt the event loop in both main and worker threads.

Confirmed facts

• Deno.readFileSync, Deno.readTextFileSync and Deno.writeFileSync are synchronous blocking APIs.
• No official Deno runtime mark or warning is emitted when a sync call exceeds a configurable blocking threshold.
• Async alternatives Deno.readFile and Deno.writeFile are non-blocking and recommended for latency-sensitive workloads.
• Blocking duration varies by OS thread scheduler, file size, and Deno version; no guaranteed constant latency exists.

Likely explanation and gaps

The capability-based permission model (--allow-read, --allow-write) governs file access but does not indicate blocking behavior. Documentation treats all sync file calls as potentially blocking without distinguishing metadata-only operations from full data reads. Version upgrades may change thread-pool sizing or API deprecation status, affecting blocking behavior.

Steps to measure actual blocking duration

1. Verify your Deno version: deno --version
2. Instrument a sync read with performance timing:

   const start = performance.now(); Deno.readTextFileSync('/path/to/file'); const end = performance.now(); console.log('Blocking duration:', end - start, 'ms')

3. Run the snippet in an isolated worker thread and observe event-loop lag via Deno.metrics() or external profiling tools.
4. If the measured duration exceeds your latency tolerance, migrate the operation to the async Deno.readFile API.

Missing diagnostic detail: If your worker thread shares the default thread pool with other async operations, blocking risk increases. Confirm thread pool configuration to refine the recommendation.