> The rule is very simple IMO, I already described it: if other execution can run while you wait for the value, it's blocking. (Edit: to be specific, other observable execution, so in your thread with write access to state you can see)

is gmtime() blocking ? Technically it needs to ask kernel to get the time so it has same potential to block as any other call

> As you already mentioned, the code that computes a trillion digits of Pi is async if its interruptible, and not async if it isn't.

Very bad definition as either

* every single code is because kernel can always reschedule thread to do something else * none of the compute code is if language runtime can't interrupt it (old versions of Go had that behaviour for tight loops IIRC) * every of compute code is if language can arbitrarily interrupt it.

> From here on you seem to not be aware of the fantastic recent developments in WebWorkers, it is now quite easy to spin up worker threads in JS, which communicate with the main thread via message passing.

That's entirely worse approach as sharing any data structures is impossible and where mutex would be enough you're now shoveling tons of data around. It's workaround at best

It's like saying "my language is multithreaded because we started many processess and communicate via redis"...