←back to thread

289 points kristoff_it | 6 comments | | HN request time: 1.353s | source | bottom
Show context
tossandthrow ◴[] No.44609913[source]
The author does not seem to have made any non-trivial projects with asynchronicity.

All the pitfalls of concurrency are there - in particular when executing non-idempotent functions multiple times before previous executions finish, then you need mutexes!

replies(3): >>44610110 #>>44610754 #>>44611759 #
1. ajross ◴[] No.44610110[source]
> All the pitfalls of concurrency are there [in async APIs]

This is one of those "in practice, theory and practice are different" situations.

There is nothing in the async world that looks like a parallel race condition. Code runs to completion until it deterministically yields, 100% of the time, even if the location of those yields may be difficult to puzzle out.

And so anyone who's ever had to debug and reason about a parallel race condition is basically laughing at that statement. It's just not the same.

replies(2): >>44610305 #>>44614633 #
2. kibwen ◴[] No.44610305[source]
> Code runs to completion until it deterministically yields

No, because async can be (quote often is) used to perform I/O, whose time to completion does not need to be deterministic or predictable. Selecting on multiple tasks and proceeding with the one that completes first is an entirely ordinary feature of async programming. And even if you don't need to suffer the additional nondeterminism of your OS's thread scheduler, there's nothing about async that says you can't use threads as part of its implementation.

replies(1): >>44610692 #
3. ajross ◴[] No.44610692[source]
And I repeat, if you think effects from unpredictable I/O completion order constitute equivalent debugging thought landscapes to hardware-parallel races, I can only laugh.

Yes yes, in theory they're the same. That's the joke.

replies(1): >>44612847 #
4. saghm ◴[] No.44612847{3}[source]
You're not reporting yourself, though, since you didn't make it clear at all in your initial comment you were talking about hardware. The previous comment you made only mentioned "parallel data races" in a conversation about software ecosystems, where both of those terms are regularly used to describe things that occur. You're laughing about dunking on people who you've run up to in the middle of a football field; no one stopped you from scoring because you didn't tell them that you're apparently playing an entirely different game on your own.
replies(1): >>44614475 #
5. ajross ◴[] No.44614475{4}[source]
The term "hardware-parallel" was to clarify that I'm talking about genuine parallelism. SMP bugs are 100% software problems solved with software techniques. You learn about them in software courses in school. They're just much harder than getting your async rig to work.
6. tossandthrow ◴[] No.44614633[source]
Idk, I work in typescript though but I do have race conditions that look exactly like those of concurrent software.

In particular promise.all([f,f,f]) where I want to ensure that I only Run the body of f a single time.