5 ms·

It would seem relatively easy to eliminate this sort of infinite loop by ensuring that all loops are finite, function call depth limited and so on. It isn't a c

It would seem relatively easy to eliminate this sort of infinite loop by ensuring that all loops are finite, function call depth limited and so on. It isn't a case where you hit the halting problem; the halting problem applies to general programs, not programs deliberately constructed out of parts with finite and calculable limits to runtime - no building the Ackermann function for example, as it contains a recursive loop. With the resources available to Apple, they really have no excuse.

kllrnohj 5d ago
Well this is easy to detect and kind of intentionally so, but the broader issue is quite a bit harder. Replace "infinite loop" with some very difficult program that simply takes 30+ seconds to finish and you're back to the same problem. It doesn't even need to be computationally difficult, you can also slam the memory bus with "far away" fetches that are randomly distributed, ensuring each fetch doesn't share a cache line with any surrounding fetches. There are popular UX effects with basically this workload, even, that's a naive implementation of a large radius gaussian blur basically...
auberonedu 5d ago
Amusingly, some of this is technically already happening. The shaders pass through downstream compilers that complain if they see what they determine to be a no-op infinite loop. To prove to the compilers that the loop terminates, most WebGPU implementations inject a u64 counter (technically a vec2<u32>) that counts down from u64:MAX and terminates the loop once it reaches 0. But that's such a large amount to count that the WindowServer is long gone. Fun discussion on this PR for wgpu, a Rust implementation of WebGPU: https://github.com/gfx-rs/wgpu/issues/6572 https://github.com/gfx-rs/wgpu/issues/6572