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).

  • 3
    I've not read the book, but I don't think your Windows example is related: Windows knows (as I recall, can't find a citation) that "task has stopped responding" when it stops processing its measure queue in good time, which is a high-level concept within Windows: the process continues to receive CPU time - and otherwise runs normally - it's just not processing messages sent to it by the OS (and since it's easy to write software which does all the work on the UI/MessagePump thread, it is easy to end up 'not responding' only to 'recover'). I'd guess the quote concerns low-level scheduling. Jun 10, 2018 at 16:59
  • (OK. I thought I'd read it on Raymond Chen's blog, and I'm sure it specified 3 seconds, but the MSDN documentation "About Messages and Message Queues" (paragraph 3) is what I was referring to) Jun 10, 2018 at 17:48

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.