I don't think so. Two threads updating the same variable would be observable in code. There's no way around it.
Re:Why choose async/await over threads?
by MuffinFlavored on Monday March 25, 2024 @01:43PM
(#39819250)
I'm referring to something like this: https://stackoverflow.com/questions/7018093/is-nodejs-really...
It's like a pedantic technical behind the scenes point I think, just trying to learn "what's true"
Looks like the spec refers to the thing-that-has-the-thread as an "agent". https://tc39.es/ecma262/#sec-agents
I don't know the details about how any implementation of a javascript execution environment allows for the creation of new agents.
I mean, yeah, if you go deep enough your OS may decide to schedule your browser thread to a different core as well. I don’t think it has any relevance here - semantically, it is executed on a single thread, which is very different from multi-threading.
Re:Why choose async/await over threads?
by MuffinFlavored on Monday March 25, 2024 @02:50PM
(#39819947)
It is executed by your runtime which may or may not behind the scenes be using a single thread for your execution and/or the underlying I/O/eventing going on underneath, no?
Re:Why choose async/await over threads?
by throwitaway1123 on Monday March 25, 2024 @09:22PM
(#39823336)
Most JS runtimes are multi-threaded behind the scenes. If you start a node process:
node -e "setTimeout(()=>{}, 10_000)" &
Then wait a second and run: ps -o thcount $!
Or on macOS: ps -M $!
You'll see that there are multiple threads running, but like others have said, it's completely opaque to you as a programmer. It's basically just an implementation detail.
Re:Why choose async/await over threads?
by throwitaway1123 on Tuesday March 26, 2024 @11:56AM
(#39829357)
If you need true parallelism of course you can opt-in to web workers (called worker threads in node), or the node-specific child_process.fork, or cluster module.
Bit of nuance (I'm not an authority of this and I don't know the current up-to-date answer across 'all' of the Javascript runtimes these days):
Isn't it technically "the developer is exposed the concept of just one thread without having to worry about order of execution (other than callbacks/that sort of pre-emption)" but under the hood it can actually be using as many threads as it wants (and often does)? It's just "abstracted" away from the user.