Regarding system interrupts and timers. Why programs sometimes still run when OS asks you to terminate or keep it going?

Question

I'm reading (just started) "Operating systems concepts" by Silberschatz, Galvin and Gagner and something called my attention when reading a basic primer on "timer" (1.5.2 on the book).

It says:

As long as the counter is positive, control is returned to the user program. When the counter becomes negative, the operating system terminates the program for exceeding the assigned time limit.

Now, I finally know how, for example, Windows knows when to pop up that message error asking whether you want to close a program that appears to be frozen/hung up or keep it running

My question is: If the OS terminates or freezes the program before asking you for input, how come sometimes that window will pop up and if you just wait the program will sometimes keep on running and will cease to appear as being frozen or hung up? (Good example: If you repeatedly click on the taskbar icon of a game while it's loading).

Answer 1

@VisualMelon's comments nailed it, but to elaborate a bit in answer form:

Silberschatz, Galvin and Gagner are talking about how an operating system kernel can manage processes: it could set a strict resource limit on CPU time for a process and kill the process (not just report that it's unresponsive) if it exceeds that limit.

People typically don't do this, because arbitrarily killing processes is usually a bad idea. However, it is supported by, e.g., Linux's ulimit -t command.

The Windows error message saying that a program appears to be frozen is operating at a much higher level than the low-level CPU time limit that Silberschatz, Galvin, and Gagner are discussing. The Windows GUI operates by messages: messages are regularly sent to running applications, to handle everything from notifying the application of mouse and keyboard events to requesting that an application redraw its screen contents after an update. At its core, then, a Windows GUI application typically has a while loop that reads messages from the message queue and processes each one.

Problems arise if the application takes too long to process a message (because it's blocked waiting for file or network I/O, or because it started a lengthy CPU task, or because it entered an endless loop). When that happens, the application isn't receiving and processing new messages, so it can't respond to input or even redraw its screen contents. That's a bad user experience, so to make it less bad, Windows will detect when applications aren't checking their message queues and pop up the message you mentioned, asking if you want to kill the application.

Of course, Windows doesn't actually know if the application has truly locked up (e.g., endless loop or deadlock) or if it's just doing something longer than expected and will resume processing messages shortly. (Windows can't know - that's the halting problem.) That's why applications will sometimes appear to recover after Windows says they're frozen.

Because of this problem, well-written Windows applications will move any potentially lengthy tasks in background threads so that they can continue to pump the message queue and thus remain responsive, but making sure that this is done everywhere it's needed is easier said than done.