One Infinite Loop

That's the address of AppleComputer. Or is it?

1 Infinite Loop - Cupertino, California - 95014

It is a play on words with the common concept of "infinite loop", found in computation.

Quite a contrast with the play on words found in Microsoft's address: OneMicrosoftWay.

You can also take OneInfiniteLoop as a design strategy: there should never be more than one infinite loop, the main loop.

Polling, such as waiting for input, often uses this technique.

What is meant by "more than one infinite loop", above?

This?:

 while (1)
   while (1)
     doStuff();

Surely it doesn't mean this sort of loop, because it's a finite loop:

 while (1) {
  if (a) break;
  doStuff();
 }

The "one infinite loop" design strategy probably refers to something like this:

 main() {
   initialize();
   while (1) {
     doStuff();
   }
 }

And the program continues running until the power is cut, until the kernel reboots, until the parent process kills the child process, until the processor is destroyed by the explosion of the warhead of the missile it is guiding, etc. Whether such a loop (or any loop for that matter) is truly infinite is a philosophical matter.

As an alternative, doStuff() might throw an exception that causes the program to exit. Again, whether this is properly termed an infinite or finite loop is a silly exercise in semantics.

The proscription against multiple infinite loops is, I presume, an assumption that the presence of any other infinite loops are unintentional. But you could have multiple infinite loops if you have multiple threads, or if there is more than one possible final state.

Yes, OneInfiniteLoop was the main design strategy for programs doing multiplexed I/O back before MultiThreadModel? became popular. Even now, it is a good principle for every thread. And some still consider SingleThreadModel? with NotificationEvents? a lot simpler, cleaner and easier to grasp a concept than MultiThreadModel? with BlockingIo?. Many server applications like ircd, and GUI kits like Tk, use OneInfiniteLoop.

The rationale of having OneInfiniteLoop (or actually unbounded, of course) is to ensure that there are no computations that might hang the whole thread: in every situation, the thread must be able to return control to the top level, which is the one infinite loop. Besides, multiple infinite loops for a single thread indicate that it has many modes of working, and so are better handled by state variables for the mode.

At DigitalEquipmentCorporation, their "infinite loop" in the VmsOperatingSystem was simply:

10: goto 10

Clearly, the OS was interrupt-driven. One of my supervisors, who claimed to be a "VMS guru", kept complaining that this one process had an abnormally high CPU utilization. He wanted me to "fix" it. Try as i might, he couldn't understand that this process was executing the (10: goto 10) loop, and the CPU utilization was, in reality, simply the idle time of the machine. Sigh.

There are ways of coding a multitasking OS so that infinite loops aren't used when there are no other runnable tasks, but it involves CPU support. The "HALT" instruction (or your processor's equivalent) needs to satisfy two things:

HALT needs to enable interrupts, even if only while the instruction is running.
HALT needs to wait for an interrupt to not only occur, but also have been processed by an ISR.

Most CPUs today have such an instruction or something very close to it. (Intel's HLT doesn't automatically enable interrupts, but as I recall, if HLT is prefixed with SEI, spurious interrupts won't cause a problem. Unfortunately, the 65816 lacks this basic protection.)

--SamuelFalvo?

Implementations of ExpertSystems tended to use this technique. Basically they kept looping around against a giant pool of conditionals until time-out or a sufficient solution(s) is reached.