The term blocking isn't well defined. How slow does an operation have to be to be considered blocking? There are no rules. Fetching google.com/robots.txt is by universal agreement a blocking operation. Reading a file from the filesystem is considered blocking in JS but may not be in other languages, especially given that very fast disks like Optane or modern NVMe Flash can be only an order of magnitude or two slower than RAM. Taking a lock may or may not be considered blocking. Computing pi to a trillion digits would usually not be considered blocking because it doesn't make any async OS API calls, even though it might cause long delays before it returns, but if the author chose to implement it as an async iterator then it could be considered blocking.
Worse, async vs not async is about latency requirements of the caller, but the function author can't know that. If you're in a UI thread doing 60fps animation maybe even reading a file would be too slow, but if you're in a script then it doesn't matter at all and you'd rather have the simpler code. You're calling the same function, the only thing that changed is the performance requirements of the user.
So "potential to block" is to some extent a makework problem that occurs in JS because V8 isn't thread safe, and V8 isn't thread safe because JS isn't, because it was designed for the web which is a kind of UI toolkit. Such toolkits are almost never thread safe because it's too much hassle to program a thread safe renderer and would make it too slow, so that browser-specific implementation constraint propagates all over the JS ecosystem.
Final major problem: some languages use async hype as an excuse to not properly support threads at all, but that's often the only way to fully exploit the capabilities of multicore hardware. If your language only does async you'll always be restricted to a single core and you have to hope your use case parallelizes embarrassingly well at the top level.
If you have threads then this whole problem just goes away. That's the core argument that Java makes with Project Loom. Instead of introducing colored functions everywhere with poorly defined and inconsistent rules over which color to use, just make threads work better. Suddenly the binary async/not async distinction becomes irrelevant.
Still, there's a good reason most languages don't do the Loom approach. It's a massive PITA to implement. The Java guys are doing it because of their heavy investment in advanced VMs, and because the Java ecosystem only rarely calls out to native code. It'd be a lot harder in an ecosystem that had less of a focus on "purity".
> The term blocking isn't well defined. How slow does an operation have to be to be considered blocking? There are no rules.
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)
> Worse, async vs not async is about latency requirements of the caller,
I disagree. To me, async vs not async is about interruptibility. 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. If you're in a UI thread doing 60fps animation, async vs not async isn't really all that relevant (barring the slight inherent overhead in calling an async function). What you need is a profiler to tell you where you have a non-interruptible block consuming your 16ms. The compiler can't know this a priori, unless you make significant restrictions to the type of code you write (no unbounded loops, for instance).
> Such toolkits are almost never thread safe because it's too much hassle to program a thread safe renderer and would make it too slow, so that browser-specific implementation constraint propagates all over the JS ecosystem.
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.
> 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"...
I'd assume you missed my edit if you hadn't directly quoted it :) The kernel interrupting the thread doesn't meet the criteria of "other execution in your thread with write access to state you can see".
Web workers aren't threads. Threading is where you have two parallel streams of execution that share mutable memory. If there's no shared memory then what you've got is more like the older term "multi-processing".
> if other execution can run while you wait for the value, it's blocking.
How does that not capture any operation with a callback, and why does this definition depend on being "in your thread"? I don't think this is a definition that's widely used or understood.
> async vs not async is about interruptibility
By this definition Java fully supports async functions, because you can call Thread.interrupt() on any thread at any time. But I think most people would say Java doesn't do what is commonly understood by "async" including the Java developers themselves.
Your definition isn't as universal as you'd like to believe:
> Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
> How does that not capture any operation with a callback
You're right that my "blocking" definition is weak. I don't use the phrase in practice (It was introduced by the parent), preferring to think in terms of interruptibility [1]. The distinction I draw is between code that can assume no other code will interrupt it and much up it's view of global state, and that which cannot. The "in your thread" distinction is there because random kernel code or code from other applications (or code from other web workers) running doesn't muck up the thread-in-question's state. Those changes can only be observed across the boundaries of an `await` ("blocking") or in callbacks from separate events.
> I think most people would say Java doesn't do what is commonly understood by "async" including the Java developers themselves.
There's room in this world for multiple definitions. See above :)
[1] The question of "blocking" is a bit interesting, the execution thread wants to make a "blocking" call, but the runtime doesn't actually execute the syscall from that thread. It spins up a new thread to make the call, that thread gets blocked by the OS, and all the while the main execution thread continues running. Thus the call was "blocking" in some sense, but not to the thread in question, which was only "interrupted". The thread in question however is executing all sorts of other code while the assistant thread is blocked, so when the assistant thread returns and execution of that task resumes from being interrupted, it must ensure all the state it had observed beforehand is still valid.
This makes things confusing: the code which executes a trillion digits of Pi is blocking, but it is not interruptible. The code which reads a file or makes a network request via a syscall might be considered blocking, but it is interruptible.
Given the existence of mmap and NFS, arbitrary reads from memory can end up being network calls. I don't think it's possible to make those async without something like kernel scheduled entities / scheduler activations, which are now a long-forgotten dream.
Yep, or any pluggable file system. Operating systems and programming languages evolved on the assumption that it's OK for operations to take arbitrary amounts of time that you can't necessarily know in advance and which may change out from underneath you, with threads being the solution (run stuff in a background thread and keep the user informed on a foreground thread). Trying to make everything async in a single thread will constantly run into papercuts like the network fs scenario because the whole infrastructure just isn't designed for it.
The term blocking isn't well defined. How slow does an operation have to be to be considered blocking? There are no rules. Fetching google.com/robots.txt is by universal agreement a blocking operation. Reading a file from the filesystem is considered blocking in JS but may not be in other languages, especially given that very fast disks like Optane or modern NVMe Flash can be only an order of magnitude or two slower than RAM. Taking a lock may or may not be considered blocking. Computing pi to a trillion digits would usually not be considered blocking because it doesn't make any async OS API calls, even though it might cause long delays before it returns, but if the author chose to implement it as an async iterator then it could be considered blocking.
Worse, async vs not async is about latency requirements of the caller, but the function author can't know that. If you're in a UI thread doing 60fps animation maybe even reading a file would be too slow, but if you're in a script then it doesn't matter at all and you'd rather have the simpler code. You're calling the same function, the only thing that changed is the performance requirements of the user.
So "potential to block" is to some extent a makework problem that occurs in JS because V8 isn't thread safe, and V8 isn't thread safe because JS isn't, because it was designed for the web which is a kind of UI toolkit. Such toolkits are almost never thread safe because it's too much hassle to program a thread safe renderer and would make it too slow, so that browser-specific implementation constraint propagates all over the JS ecosystem.
Final major problem: some languages use async hype as an excuse to not properly support threads at all, but that's often the only way to fully exploit the capabilities of multicore hardware. If your language only does async you'll always be restricted to a single core and you have to hope your use case parallelizes embarrassingly well at the top level.
If you have threads then this whole problem just goes away. That's the core argument that Java makes with Project Loom. Instead of introducing colored functions everywhere with poorly defined and inconsistent rules over which color to use, just make threads work better. Suddenly the binary async/not async distinction becomes irrelevant.
Still, there's a good reason most languages don't do the Loom approach. It's a massive PITA to implement. The Java guys are doing it because of their heavy investment in advanced VMs, and because the Java ecosystem only rarely calls out to native code. It'd be a lot harder in an ecosystem that had less of a focus on "purity".