← ClaudeAtlas

blocking-and-nonblocking-iolisted

Four things routinely conflated into one: a blocking API, a blocked OS thread, non-blocking I/O at the syscall, and an asynchronous programming model. Covers which JDK operations unmount a virtual thread and which capture the carrier, the difference between capture-with-compensation and pinning, the socket poller behind blocking socket calls, file I/O as the case Loom does not fix, and what blocking an event loop costs. Use when someone says virtual threads make I/O non-blocking, when a file-heavy workload on virtual threads grows the carrier pool, when a blocking call sits inside a Netty or Reactor pipeline, when jdk.virtualThreadScheduler.maxPoolSize is raised to fix a symptom, or when an argument turns on whether the model or the syscall is the bottleneck. Not choosing between the two models (reactive-and-virtual-thread-selection), continuation mechanics and pinning diagnosis (virtual-threads-internals), demand signalling (reactive-backpressure), or copy avoidance (io-uring-and-zero-copy).
robsonkades/agent-skills · ★ 2 · AI & Automation · score 68
Install: claude install-skill robsonkades/agent-skills
# Blocking and Non-Blocking I/O ## Purpose Keep four distinct properties distinct, because every confused architecture argument about virtual threads and reactive programming comes from collapsing them: ```text Blocking API the caller may wait for this call's specified result Blocked OS thread a kernel-schedulable entity is parked and unavailable Non-blocking I/O no wait for readiness; partial progress or would-block is possible Asynchronous model completion is represented separately, e.g. a stage or callback ``` A virtual thread reading a supported socket path without an enclosing pinning frame uses a **blocking API**, does **not** dedicate a blocked carrier to that request, sits on top of **non-blocking I/O** plus a shared poller in the current JDK implementation, and is written in a **synchronous** model. All four at once. Any sentence that treats them as the same axis is wrong somewhere. Define what completion means before releasing resources: a read may return fewer bytes than requested, and a streaming response may return before its body is consumed. Readiness, API return, transfer completion and a remote business effect are different milestones; none alone proves the others. The classification reference gives a concrete streaming example. ## Compatibility and evidence Virtual-thread APIs require Java 21 (standard, no preview flags). Implementation guidance here targets HotSpot JDK 21–25; the monitor behavior changes at JDK 24. Before applyin