This does not appear to be a concurrency bug though?
replyOf course it's a concurrency bug. It races sending data to the kernel against the kernel sending data to the network. If the wrong one wins the bug occurs.
replyBut it did not take 2 threads within the same application to interact in a bad way on data the system controlled to cause this problem.
replyThis reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.
Concurrency bugs don't have to be within a single process.
replyBy that definition, every write() call that doesn't check for EAGAIN is a concurrency bug you're racing the disk controller. The term stops meaning anything.
replyIsn't that like saying there can never be a language with safe concurrency since the code could interact with C code that segfaults?
I dunno this kinda reminds me of the 10/10 Rust CVE that turned out to be cmd.exe on Windows not sanitizing inputs and languages like Java just labeled it "won't fix".
replyYou mean the one where Windows doesn't have argv the way Unix does, and instead just has a single string that is interpreted slightly differently by each executable? That is a language making false assertions about how the underlying platform works, causing an impedance mismatch that is impossible to fix.
replyYeah, the one most languages (except for Rust)* decided was not a language problem and did not fix.
reply*should clarify, Node.js, PHP, and Haskell did ship patches. Python, Ruby, Erlang, and Go opted for documentation updates; Java went "won't fix."
“ a race condition that occurred only under specific conditions — in the hyper library”
reply