Hacker News Reader

Comment by c0balt | Hacker News Reader

This does not appear to be a concurrency bug though?

Of 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.

Isn'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".

You 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.

Yeah, the one most languages (except for Rust)* decided was not a language problem and did not fix.

*should clarify, Node.js, PHP, and Haskell did ship patches. Python, Ruby, Erlang, and Go opted for documentation updates; Java went "won't fix."

But 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.

This 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.

By 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.

“ a race condition that occurred only under specific conditions — in the hyper library”

Fearless concurrency has always been regarding data races. There's no fear of undefined behaviour due to a race condition.

Rust has never promised to solve race conditions as a whole.

Reply on news.ycombinator.com