Subprocess tree

In order to facilitate the construction of debugger subprocesses, and service subprocesses such as the SCOPE simulator and the disk/directory system, a control relation was defined among the subprocesses of a process. This took the form of a tree, which we called the subprocess tree. An ancestor subprocess had complete control over all descendents. Under certain conditions, a subprocess and a descendant could be swapped into CM simultaneously. A program running in the ancestor subprocess would then have direct access to the logical memory of the descendant. The memory of the descendant would appear at high addresses within the memory of the ancestor. Moreover, a similar relationship held for the local C-lists of the two subprocesses, as well as the maps. (The local C-list of the second appeared as an extension fo the local C-list of the ancestor.) At all times, a certain set of subprocesses within the tree, the full-path, was defined. This determined which subprocesses were to be swapped into CM. The Full-path had a fairly complicated definition, which guaranteed that if a subprocess called an ancestor, both would be in the current full-path, as well as any intermediate subprocesses in the tree. The subprocess tree was used to determine how to process errors and interrupts. Certain conditions (such as an illegal parameter) occurring during an action created an error. An error always caused some subprocess to be called, which would begin execution at a special error entry point. The subprocess to be called was determined during a scan of the tree, starting with the subprocess in execution at the time of the error, and proceeding towards the root. Each subprocess had an error-mask which specified which kinds of errors it wished to process. Upon calling a particular subprocess with an error, the corresponding bit in its error mask would be turned off. In order to receive similar errors later, the subprocess was required to turn the bit back on. A program in one process could direct an interrupt at a named subprocess in another process. (It named the subprocess by giving its class-code.) Information was associated with each subprocess to determine if it would accept interrupts. A scan, starting at the named subprocess and proceeding towards the root, determined which subprocess would actually receive the interrupt. That subprocess was then called as soon as it or one of its descendents was executing. The ancestor relationship had a number of intended applications. These included the construction of debugger type subprocesses and the scope system simulator. The Disk system intended to make use of the facility to perform reads and writes for portions of a file residing on the disk. The algorithms for handling errors and interrupts attempted to prevent a descendent subprocess from unexpectedly getting control over an ancestor. Only an ancestor of a subprocess could unexpectedly gain control. We saw this as a generalization of the usual monitor-user mode facility.