Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

That's going to make data race conditions invisible, no?

How will developers cope with that?



To an extent yes, but consider the context: front end scripting

The javascript threading model is that there is a single thread executing so within a given bit of code you can be reasonably sure things are safe. The hyperscript runtime only allows one instance of a given event handler to execute at a time (unless otherwise specified) so the primary source of concurrency issues (the same code executing concurrently) is typically not an issue. By structuring your code such that it is on the same element (perhaps triggered by events elsewhere) you can effectively synchronize code in an intuitive manner.

I certainly wouldn't recommend the language for the back end though!


My team just spent three weeks hunting down a race condition in JavaScript integration tests. Turns out it was a missing `await`. So, I wouldn't claim that JavaScript is anywhere near safe :)

Admittedly, this was back-end, so it's possible that the situation is simpler in the front-end.

Good luck with your project!


Data races happen when there are multiple writers/readers of the same data. If one virtual thread of execution is multiplexed on several OS threads/workers/callbacks/you name it, there's still only one reader/writer at a time, because different parts of a multiplexed function don't run at the same time, they go one after another sequentially as before, with the difference is that there are now implicit continuation points where execution can hop from thread to thread (callback to callback). Can't say for hyperscript, but generally you need to protect your data with the same synchronization primitives as before, such as locks for example. It's only incompatible with thread locals and thread affinity, I'm not sure if JS has those.


If your data is composite (i.e. a JavaScript object or array) and you have several Promise-based flows of execution (technically not a virtual thread by most definitions of the term, but still a scheduled flow of execution) that end up reading/writing sub-parts of your piece of data in unpredictable order. That's basically a data race, in JavaScript. I've had to debug some of those.

As a side-note, some forms of data races (for perhaps a slightly looser definition of the term) can even happen without explicit asynchronicity, just with callbacks/synchronous events.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: