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 75

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 method returns when the operation is done Blocked OS thread a kernel-schedulable entity is parked and unavailable Non-blocking I/O the syscall returns immediately with whatever is ready Asynchronous model the code is expressed as callbacks or stages, not statements ``` A virtual thread doing `socket.read()` 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. ## 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 applying it, inspect compiler/toolchain settings, the deployed JDK vendor and version, OS, resolved client/framework versions, transport and scheduler configuration. These can differ from the development JDK. Recheck implementation claims for other releases; do not upgrade the project or add instrumentation dependencies merely to apply this skill. ## Workflow 1. **Ask which property the claim is about.** "Is this blocking?" is fo