Oh, the example in the last post was not a good example. I was wrong -- it will cycle infinitely.
I was trying to translate that scenario from the "event-manager code," which is similar, but have a distinct difference, i.e., the event-manager code has a "wait-state" so it waits rather than continually executing through the loop. When it is in the wait state (for an event to occur), it is not wasting or stealing any CPU time. That is why it won't tie up the system in the event-manager code:
do
{
WaitForEvent(); //the events can be mouse-event, keyboard-event, disk-event, network-event, clock-event, etc.
ProcessEvent(); //send the event to the appropriate event-handler to do something with it
} while (true);
So, in this case, you would not want to exit the event-listening code. Otherwise, the computer will stop responding to any external event entirely, i.e., it is in a coma, and the system hangs. So long as the system is up, it will need to listen to some sort of events to execute accordingly.