3 ms·
To have a race condition, you first have to have a shared state. And in my experience, for almost all applications where NodeJS is a good fit (usually a CPU-lig
by golergka 6y ago
To have a race condition, you first have to have a shared state. And in my experience, for almost all applications where NodeJS is a good fit (usually a CPU-light application that is serving web requests, each of them independent of others, and waiting for a long time on IO, usually different database requests and other external services), shared state is already a bad pattern.
- chrisseaton 6y ago> To have a race condition, you first have to have a shared state. I think you're possibly confusing 'race condition' with 'data race'. You need shared state for a data race, but not for a race condition. For example if you send a request to two web services, then wait for responses from either, then that's a race condition on which result comes back first, because the non-deterministic timing can change program behaviour. And that's not even necessarily a problem or a bug. You can easily get race conditions even in a system that tries to minimise shared state, such as Erlang, even though they protect you from data races.
- dnautics 6y agoTechnically in your example the shared state is the network.
- chrisseaton 6y agoNo the situation still holds if you send two requests on different network cards to entirely different networks that share nothing.
- dnautics 6y agoIn that case the shared state is the observer.
- chrisseaton 6y agoI don't think that's really a meaningful or useful definition of shared state for these purposes.
- dnautics 6y agoIt is! You should consider your brain as basically a database distant from the software, when you observe a race condition it's the same phenomenon as writing to a database (except you don't have a transactional system that gets activated by default).
- gpderetta 6y agoshared state and message passing are dual to each other.