It just occurred to me, if an entire mobile OS and its apps were written in a language like Go, this sort of bug could conceivably never happen, because with a few coding conventions, nothing would ever block.
That isn't a fix. The problem isn't blocking as such but rather latency. If for example a screen refresh and reading from 10 different network connections were all done in one thread (non-blocking) it could still take some time before the screen refresh code gets to run.
60fps gives you 16ms per frame. Correctly written Android apps (and iOS for that matter) are expected to do work on secondary threads, and keep UI only code in the UI thread. Of course many applications don't quite stick to that.
In the Android developer settings you can make it whine about work being done in the UI thread (eg storage/network activity - StrictMode). You can also make it flash a red border whenever the UI thread blocks. In Android 4.0 I used to see a lot of red border from Google's own apps. In 4.2 it happens a lot less often.
The problem isn't blocking as such but rather latency. If for example a screen refresh and reading from 10 different network connections were all done in one thread (non-blocking)
Yes, but in the sort of environment I just described, if things are done correctly, the thread handling UI updates would not only never block, it would never be waiting on anything high latency.
In the Android developer settings you can make it whine about work being done in the UI thread
> Yes, but in the sort of environment I just described, if things are done correctly, the thread handling UI updates would not only never block, it would never be waiting on anything high latency.
That is already the case today for well written apps on Android (Java) and Objective C (iOS). Rewriting in Go wouldn't be a solution. It is how the execution is structured in any language.
Well, no. You still have to wait for computation, you still have to wait for network... and you still have to wait for entropy generators, if you use them.
It would possible for a part of application (thread) that do not rely on random numbers to be more responsive. But you do not need OS rewrite for that. And, of course, if you are aware that you are waiting for random numbers to draw a map, you want to do something with that in the first place. :-)
We had a large system written in go start giving us random identifiers that weren't random (something like dlsfaioghoph0000000000) due to entropy depletion. On a technical level it was drawing from non blocking /dev/urandom...it wasn't blocking but it wasn't exactly failing gracefully either.
