Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

20
  • 14
    This answer could benefit from additionally explaining of why splitting programs into many small ones saves memory use: A program had to be able to fit in-memory to run, but only the currently running program. Every other program was swapped out to disk in early Unix, with only one program even swapped into actual RAM at a time. So the CPU would run one program, which would write to a pipe (which back then was on disk), swap out that program and swap in the one that read from the pipe. Elegant way to turn a logically parallel assembly line into incremental serialized execution. Commented Jun 20, 2018 at 17:06
  • 6
    @malan: Multiple processes can be started and can be in a runnable state at the same time. But at most one process can be executing on each physical CPU at any given time, and it's the job of the kernel's process scheduler to allocate "slices" of CPU time to each runnable process. In modern systems, a process that is runnable but not currently scheduled a CPU timeslice usually remains resident in memory while it's waiting for its next slice, but the kernel is allowed to page the memory of any process out to disk and back into memory again as it finds convenient. (Handwaving some details here.) Commented Jun 20, 2018 at 19:09
  • 5
    Processes on either side of a pipe can behave effectively like co-routines: one side writes until it fills up the buffer and the write blocks, at which point the process can't do anything with the rest of its timeslice and it goes into an IO wait mode. Then the OS gives the remainder of the timeslice (or another upcoming timeslice) to the reading side, which reads until there's nothing left in the buffer and the next read blocks, at which point the reader process can't do anything with the rest of its timeslice and yields back to the OS. Data goes through the pipe one buffer's worth at a time. Commented Jun 20, 2018 at 19:13
  • 6
    @malan The programs are started "at the same time" conceptually on all Unix systems, just on modern multiprocessor systems with enough RAM to hold them that means they're literally all held in RAM at the same time, while on a system that can't hold them all in RAM at the same time, some get swapped out to disk. Also note that "memory" in a lot of contexts means virtual memory which is the sum of both RAM space and swap space on disk. Wikipedia is focusing on the concept rather than on the implementation details, especially because how really old Unix did things is less relevant now. Commented Jun 20, 2018 at 21:28
  • 2
    @malan Also, the contradiction you are seeing comes from the two different meanings of "memory" (RAM vs RAM+swap). I was talking about hardware RAM only, and in that context only the code currently being executed by the CPU needs to fit in RAM (which was what was effecting the decisions Kernighan is talking about), while in the context of all programs being logically executed by the OS at a given time (at the abstract level provided on top of time slicing) a program just needs to fit within the entire virtual memory available to the OS, which includes swap space on disk. Commented Jun 20, 2018 at 21:40