4 ms·
I mean, if something like this is behind a promise or an async call, that probably means that there's I/O involved (no point using async to access local in-memo
by DrJokepu 7y ago
I mean, if something like this is behind a promise or an async call, that probably means that there's I/O involved (no point using async to access local in-memory data), which means that the local locking primitive won't be incredibly useful, you're going to have to lock it via whatever mechanism the I/O channel (or some API using the I/O channel) provides, such as file locking or some API call or something.
- ithkuil 7y agoYep, that's the benefit of having to explicitly mark each function explicitly as async. I've heard a lot of people complaining that it's painful, especially during refactorings since it bubbles up, but that's precisely the point: it allows you to know (and choose) whether a function can or cannot be executed interleaved with something else. That said, if new developers just blindly use async/await without understanding what's going on ... well that's another problem. The field is filled with foot-guns, for some definition of guns (and for some definition of foot). The problem with C, or better the problem with pre-emptive multitasking in general, is that even relatively knowledgeable developers were constantly hitting subtle issues with the memory model. Consider the good old trap of efficiently lazy-initializing a Singleton in Java: https://en.m.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java https://en.m.wikipedia.org/wiki/Double-checked_locking#Usage...