TOPS-20 Monitor Calls User's Guide
Chapter 5 Process structure
As stated in Chapter 1, the TOPS-20 operating system allows each job to have multiple processes that can run simultaneously. Each process has its own environment called its address space. Associated with the environment is the program counter (PC) of the process and a well-defined relationship with other processes in the job. In TOPS-20, the term fork is synonymous with the term process.
The TOPS-20 operating system schedules the running of processes, not entire jobs. A process can be scheduled independent of other processes because it has a definite existence: its beginning is the time at which it is created, and its end is the time at which it is killed. At any point in its existence, a process can be described by its state, which is represented by a status word and a PC word (refer to Section 5.9).
The relationships among processes in a job are shown in the diagram below. Each process has one immediate superior process (except for the top-level process) and can have one or more inferior processes. Two processes are parallel if they have the same immediate superior. A process can create an inferior process but not a parallel or superior process.
--------------
| Top-Level |
| Process |
--------------
|
----------------------|--------------------
| | |
------------- ------------- -------------
| Process 1 | | Process 2 | | Process 3 |
------------- ------------- -------------
| |
------------- -------------
| Process 4 | | Process 5 |
------------- -------------
Process 1 is the superior process of process 4, and process 3 is the superior of process 5. Processes 4 and 5 are the inferiors of processes 1 and 3, respectively. Process 2 has no inferior process. Processes 1, 2 and 3 are parallel because they have the same superior process (the top-level process). Processes 4 and 5, although at the same depth in the structure, are not parallel because they do not have the same superior process. Process 1 created process 4 but could not have created any other process shown in the structure above.
5.1 Uses for multiple processes
A multiple-process job structure allows:
- One job to have more than one program runnable at the same time. These programs can be independent programs, each one compiled, debugged, and loaded separately. Each program can then be placed in a separate process. These processes can be parallel to each other, but are inferior to the main process that created them. This use allows parallel execution of the individual programs.
- One process to wait for an event to occur (for example, the completion of an I/O operation) while another process continues its computations. Communication between the two processes is such that when the event occurs, the process that is computing can be notified via the software interrupt system. This use allows two processes within a job to overlap I/O with computations.
One application of a multiple-process job structure is the following situation: a superior process is responsible for accepting input from various terminals. After receiving this input, the process sends it to various inferior processes as data. These inferior processes can then initiate other processes, for example, to write reports on the data that was received.
------------------
--------- | | ---------
| | | Process that | | |
| TTY |------| Accepts input |-----| TTY |
| | | from Terminals | | |
--------- | | ---------
------------------
|
-------------|-------------
| | |
| | |
------- ------- -------
| | | | | | Processes that
| | | | | | Receive the
| | | | | | input as Data
------- ------- -------
| | |
| | |
------- ------- -------
| | | | | | Processes that
| | | | | | Write Reports
| | | | | | on the Data
------- ------- -------
Another application is that used for the user interface on the DECSYSTEM-20. On the DECSYSTEM-20, the top-level process in the job structure is the Command Language. This process services the user at the terminal by accepting input. When the user runs a program (for example, MACRO, FORTRAN), the Command Language process creates an inferior process, places the requested program in it, and executes it. The Command Language can then wait for an event to occur, either from the program or from the user. An event from the program can be its completion, and an event from the user can be the typing of a certain terminal key (CTRL/C, for example).
5.2 Process communication
A process can communicate with or control other processes in the system in several ways:
- direct process control
- software interrupts
- IPCF and ENQ/DEQ facilities
- memory sharing
5.2.1 Direct Process Control
A process can create and control other processes inferior to it within the job structure. The superior process can cause the inferior process to begin execution and then to suspend and later resume execution. After the inferior process has completed its tasks, the superior process can delete the inferior from the job structure.
Some of the monitor calls used for direct process control are: CFORK%, to create a process; SFORK%, to start a process; WFORK%, to wait for a process to terminate; RFSTS%, to obtain the status of a process; and KFORK%, to delete a process. Refer to the TOPS-20 Monitor Calls Reference Manual for descriptions of additional monitor calls dealing with process control.
5.2.2 Software Interrupts
The software interrupt facility enables a process to receive asynchronous signals from other processes, the system, or the terminal user or to receive signals as a result of its own execution. For example, a superior process can enable the interrupt system so that it receives an interrupt when one of its inferiors terminates. In addition, processes within a job structure can explicitly generate interrupts to each other for communication purposes.
Some of the monitor calls used when communication occurs via the software interrupt system are: SIR%, to specify the interrupt tables; EIR%, to enable the interrupt system; AIC%, to activate the interrupt channels; and IIC%, to initiate an interrupt on a channel. Refer to Chapter 4 and Section 5.10 for more information.
5.2.3 IPCF and ENQ/DEQ Facilities
The Inter-Process Communication Facility (IPCF) enables processes and jobs to communicate by sending and receiving informational messages. The MSEND% call is used to send a message, the MRECV% call is used to receive a message, and the MUTIL% call is used to perform utility functions. Refer to Chapter 7 for descriptions of these calls.
The ENQ/DEQ facility allows cooperating processes to share resources and facilitates dynamic resource allocation. The ENQ% call is used to obtain a resource, the DEQ% call is used to release a resource, and the ENQC% call is used to obtain status about a resource. Refer to Chapter 6 for descriptions of these calls.
5.2.4 Memory Sharing
Each page or section in a process' address space is either private to the process or shared with other processes. Pages are shared among processes when the same page is represented in more than one process' address space. This means that two or more processes can identify and use the same page of physical storage. Even when several processes have identified the same page, each process can have a different access to that page, such as access to read or write that page.
A type of page access that facilitates sharing is the copy-on-write access. A page with this access remains shared as long as all processes read the page. As soon as a process writes to the page, the system makes a private copy of the page for the process doing the writing. Other processes continue to read and execute the original page. This access provides the capability of sharing as much as possible but still allows the process to change its data without changing the data of other processes. A monitor call used when sharing memory is PMAP%. Refer to Section 5.6.2 for more information.
5.3 Process identifiers
In order for processes to communicate with each other, a process must have an identifier, or handle, for referencing another process. When a process creates an inferior process, it is given a handle on that inferior. This handle is a number in the range 400001 to 400777 and is meaningful only to the process to which it is given (that is, to the superior process). For example, if process A creates process B, process A is given a handle (for example, 400003) on process B. Process A then specifies this handle when it uses monitor calls that refer to process B. However, process B is not known by this handle to any other process in the structure, including itself. The handle 400003 may in fact be known to process B, but it would describe a process inferior to process B. For this reason, process handles are sometimes called "relative fork handles" because they are relative to the process that created them.
There are several standard process handles that are never assigned by the system but have a specific meaning when used by any process in the structure. These handles are used when a process needs to communicate with a process other than its immediate inferior or with multiple processes at once. These handles are described in Table 5-1.
| Number | Symbol | Meaning |
|---|---|---|
| 400000 | .FHSLF | The current process (or self). |
| 400000+n | Process n, relative to the current process. | |
| 200000 | FH%EPN | Extended page number (see PM%EPN in PMAP%). When used in conjunction with the above two forms, this bit indicates that addresses and/or page numbers are interpreted as absolute, not relative to the PC section of the program executing the JSYS. This bit has no meaning for programs that do not use extended addressing. |
| -1 | .FHSUP | The immediate superior of the current process. |
| -2 | .FHTOP | The top-level process in the job structure. |
| -3 | .FHSAI | The current process and all of its inferiors. |
| -4 | .FHINF | All of the inferiors of the current process. |
| -5 | .FHJOB | All processes in the job structure. |
Consider the job structure below.
-------
| A |
-------
|
---------------|---------------
| | |
------- ------- -------
| B | | C | | D |
------- ------- -------
|
--------|-------
| |
------- -------
| E | | F |
------- -------
|
-------|--------
| |
------- -------
| G | | H |
------- -------
The following indicates the specific process or processes being referenced if process E gives the handle:
| .FHSLF | refers to process E |
| .FHSUP | refers to process D |
| .FHTOP | refers to process A |
| .FHSAI | refers to processes E, G, and H |
| .FHINF | refers to processes G and H |
| .FHJOB | refers to processes A through H |
The process must have the appropriate capability enabled in its capability word to use the handles .FHSUP, .FHTOP, and .FHJOB (refer to Section 5.5.1).
Process E can reference one of its inferiors (for example, G) with the handle it was given when it created the inferior. Process E can reference other processes in the structure (for example, F) by executing the GFRKS% monitor call to obtain a handle on the desired process. Refer to the TOPS-20 Monitor Calls Reference Manual for a description of the GFRKS% call.
5.4 Overview of monitor calls for processes
Monitor calls exist for creating, loading, starting, suspending, resuming, interrupting, and deleting processes. When a process is created, its address space is assigned, and the process is added to the job structure of the creating process. The contents of its address space can be specified at the time the process is created or at a later time. The process can also be started at the time it is created. A process remains potentially runnable until it is explicitly deleted or its superior is deleted.
A process may be suspended if one of the following conditions occurs:
- The process executes an instruction that causes a software interrupt to occur, and it is not prepared to process the interrupt.
- The process executes the HALTF% monitor call.
- The superior process requests suspension of its inferior.
- The superior process is suspended. When a process is suspended, all of its inferior processes are also suspended.
- A monitor call is trapped. (Refer to TFORK% monitor call in the TOPS-20 Monitor Calls Reference Manual).
5.5 CREATING A PROCESS
A process creates an inferior process by executing the CFORK% (Create Process) monitor call. This monitor call allows the caller to specify the address space, capabilities, initial contents of the ACs, and PC for the inferior process and to start the execution of the inferior.
The CFORK% call accepts two words of arguments in AC1 and AC2.
| AC1: | characteristics for the inferior in the left half, and PC address for the inferior in the right half. |
| AC2: | address of a 20 (octal) word block containing the AC values for the inferior. |
The characteristics for the inferior process are described in Table 5-2.
| Bit | Symbol | Meaning |
|---|---|---|
| 0 | CR%MAP | Set the map of the inferior process to the same as the map of the
superior (creating) process. This means that the superior and the inferior
will share the same address space. Changes made by one process will be
seen by the other process.
If this bit is not on in the call, the inferior's map will contain all zeros. If desired, the creating process can then use PMAP or GET to add pages to the inferior's map. |
| 1 | CR%CAP | Set the capability word of the inferior process to the same as the
capability word of the superior process. (Refer to Section 5.5.1 for the
description of the capability word.)
If this bit is not on in the call, the inferior will have no special capabilities. |
| 2 | Reserved for Digital (must be 0). | |
| 3 | CR%ACS | Set the ACs of the inferior process to the values beginning at the
address given in AC2.
If this bit is not on in the call, the inferior's ACs will be set to zero, and the contents of AC2 is ignored. |
| 4 | CR%ST | Set the PC for the inferior process to the address given in the right
half of AC1 and start execution of the inferior.
If this bit is not on in the call, the right half of AC1 is ignored, and the inferior is not started. If desired, the creating process can then use SFORK% or XSFRK% to start the newly created process. |
| 18-35 | CR%PCV | PC value for inferior process if CR%ST is on. |
If execution of the CFORK% call is not successful, the inferior process is not created and an error code is returned, as described in Section 1.2.2.
If execution of the CFORK% call is successful, the inferior process is created and its process handle is returned in the right half of AC1. This handle is then used by the superior process when communicating with its inferior process. The execution of the program in the superior process continues at the second instruction following the CFORK% call. The inferior begins execution at the location contained in bits 18-35 (CR%PCV) if CR%ST is specified.
Assume that process A executes the CFORK% monitor call twice to create two parallel inferior processes. This is represented pictorially below.
-------------------------
| Process A |
| Creates Process B |
| by Executing a CFORK |
-------------------------
|
|
-------------------------
| Process B is Created |
| and Its Handle is |
| |
-------------------------
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-------------------------
| Process A Executes |
| Another CFORK to |
| Create Process C |
-------------------------
|
---------------------|---------------------
| |
------------------------- ------------------------
| | | Process C is Created |
| Process B | | and Its Handle |
| | | Given to Process A |
------------------------- ------------------------
Note that process A has been given two handles, one for process B and one for process C. Process A can refer to either of its inferiors by giving the appropriate handle or to both of its inferiors by giving a handle of -4 (.FHINF).
5.5.1 Process Capabilities
When a new process is created, it is given the same capabilities as its superior, or it is given no special capabilities. This is indicated by the setting of the CR%CAP bit in the CFORK% call. The capabilities for a process are indicated by two capability words. The first word indicates if the capability is available to the process, and the second word indicates if the capability is enabled for the process. This second word is the one being set by the CR%CAP bit in the CFORK% call.
Types of capabilities represented in the capability words are job, process, and user capabilities. Each capability corresponds to a particular bit in the capability words and thus can be activated and protected independently of the other capabilities. Refer to the TOPS-20 Monitor Calls Reference Manual for more information on the capability words.
5.6 Specifying the contents of the address space of a process
Once a process is created, the contents of its address space can be specified. This can be accomplished in one of three ways. As mentioned in Section 5.5, bit CR%MAP can be set in the CFORK% call to indicate that the address space of the inferior process is to be the same as the address space of the creating process. In addition, the creating process can execute the GET% monitor call to map specified pages from a file into the address space of the inferior process. Finally, the creating process can execute the PMAP% monitor call to map specified pages from another process into the address space of the inferior process.
If the creating process does not specify the contents of the inferior's address space, the address space will be filled with zeros.
5.6.1 GET% Monitor Call
The GET% monitor call gets a save file, copying or mapping it into the process as appropriate. It updates the monitor's data base for the process by copying the entry vector and the list of program data vector addresses (PDVAs) from the save file. (See the .POADD function of the PDVOP% monitor call.)
This call can be executed for either sharable or nonsharable save files that were created with the SSAVE% or SAVE% monitor call, respectively. The file must not be open by any process in the user's job. (Refer to the TOPS-20 Monitor Calls Reference Manual for more information regarding the PDVOP%, SSAVE%, and SAVE% monitor calls.)
The GET% monitor call accepts two words of arguments in AC1 and AC2. The first word specifies the handle of the desired process, flag bits, and the JFN of the desired file. The second word specifies where the pages from the file are to be placed in the address space of the process. Thus,
| AC1: | process handle,,flag bits and a JFN |
| AC2: | lowest process page number in left half, and highest process page number in right half; or the address of an argument block. If this AC contains page numbers, those page numbers control the parts of memory that are loaded when GT%ADR is on in AC1. |
Table 5-3 describes the bits that can be set in AC1.
| Bit | Symbol | Meaning |
|---|---|---|
| 19 | GT%ADR | Use the memory address limits given in AC2. If this bit is off, all existing pages of the file (according to its directory) are mapped. |
| 20 | GT%PRL | Preload the pages being mapped (move the pages immediately.) If this bit is off, the pages are read in from the disk when they are referenced. |
| 21 | GT%NOV | Do not overlay existing pages and do return an error. If this bit is off, existing pages will be overlaid. |
| 22 | GT%ARG | If this bit is on, AC2 contains the address of an argument block. |
| 24-25 | GT%JFN | JFN of the save file. |
The format of the argument block is described in Table 5-4.
| Word | Symbol | Meaning |
|---|---|---|
| 0 | .GFLAG | Flags that indicate how the rest of the argument block is to be used. |
| 1 | .GLOW | Number of the lowest page in the process into which a file page gets loaded. This page must be within the section specified by .GBASE. |
| 2 | .GHIGH | Number of the highest page in the process into which a file page gets loaded. This page must be within the section specified by .GBASE. |
| 3 | .GBASE | Number of the section into which the file pages are loaded. You can specify the section for single-section save files only; use of this word with a multiple-section save file causes an error. The file pages are loaded into this section of memory regardless of the section specified in the save file. |
Table 5-5 describes the flag bits defined for use in .GFLAG.
| Bit | Symbol | Meaning |
|---|---|---|
| 0 | GT%LOW | .GLOW contains the number of the lowest page within the process to use. |
| 1 | GT%HGH | .GHIGH contains the number of the highest page within the process to use. |
| 2 | GT%BAS | .GBASE contains the number of the section to use. |
When the pages of the file are mapped into pages in the process's address space, the previous contents of the process pages are overwritten. Any full pages in the process that are not overwritten are unchanged. Any portions of process pages for which there is no data in the file are filled with zeros.
For example, a GET% call executed for a file that contains 2 1/2 pages sets up the process' address space as shown in the following diagram.
Process File
------------ - - - - - - - - ---------
Page 1 | Data | / | Data | Page 1
| | | | |
| | | | |
| | / GET | |
|----------| \ Call |-------|
Page 2 | Data | | | Data | Page 2
| | | | |
|----------| | |-------|
Page 3 | Data | \ | Data | Page 3
|----------| - - - - - - - - |-------|
| | | EOF |
| | | |
| 0 | | |
|----------| ---------
| |
Page 4 - |Unchanged |
Page 512 | |
------------
After execution of the GET% call, control returns to the user's program at the instruction following the call. If an error occurs, a software interrupt is generated, which the program can process via the software interrupt system.
5.6.2 PMAP% Monitor Call
The PMAP% monitor call is used to map pages from one process to the address space of a second process. Data is not actually transferred; only the contents of the page map of the second (that is, destination) process are changed.
The PMAP% monitor call accepts three words of arguments in AC1 through AC3. The first word contains the handle and page number of the first page to be mapped in the source process (that is, the process whose pages are being mapped). The second word contains the handle and page number of the first page to be mapped in the destination process (that is, the process into which the pages are being mapped). The third word contains a count of the number of pages to map and bits indicating the access that the destination process will have to the pages mapped. Thus,
| AC1: | source process handle in the left half, and page number in the process in the right half. |
| AC2: | destination process handle in the left half, and page number in the process in the right half. |
| AC3: | count of number of pages to map and the access bits. |
The count and access bits that can be specified in AC3 are described in Section 3.5.6.1.
Upon successful execution of the PMAP% call, addresses in the destination process actually refer to addresses in the source process. The contents of the destination page previous to the execution of the call have been deleted. The access requested in the PMAP% call is granted if it does not conflict with the current access of the destination page (that is, an AND operation is performed between the specified access and the current access). Control returns to the user's program at the instruction following the PMAP% call. If an error occurs, an illegal instruction trap is generated, which the program can process via the software interrupt system or with an ERJMP or ERCAL instruction.
5.7 Starting an inferior process
A program in an inferior process can be started in one of two ways. As mentioned in Section 5.5, the superior process can specify in the CFORK% call the PC for the inferior process and start its execution. Alternatively, the superior process, after executing the CFORK% call to create an inferior process, can execute the SFORK% (Start Process) monitor call to start it.
The SFORK% monitor call accepts two words of arguments in AC1 and AC2.
| AC1: | flags,,process handle
Flags:
| ||
| AC2: | the PC of the process being started. The PC contains flags in the left half and the process starting address in the right half. This call obtains the section number of the PC from the entry vector of the process. |
There are two alternative ways to start processes: XSFRK% (see Section 8.3.2) or SFRKV% (see the TOPS-20 Monitor Calls Reference Manual).
The process handle given in AC1 cannot refer to a superior process, to more than one process (for example, .FHINF), or to a process that has already been started.
After execution of the SFORK% call, control returns to the user's program at the instruction following the call. If an error occurs, a software interrupt is generated, which the program can process via the software interrupt system.
5.8 Inferior process termination
The superior process has one of two ways in which it can be notified when one or more of its inferiors terminate execution: via the software interrupt system or by executing the WFORK% monitor call. An inferior process will terminate normally when it executes a HALTF% monitor call. Alternatively, the process will terminate abnormally when it executes an instruction that generates a software interrupt, such as an illegal instruction, and it has not activated the appropriate channel.
By activating channel .ICIFT (channel 19) for inferior process termination and enabling the software interrupt system, the superior process will receive an interrupt when one of its inferiors terminates. (Refer to Section 4.6 for information on activating channel .ICIFT.) The interrupt occurs when any inferior process terminates. Use of the interrupt system allows the superior to do other processing until an interrupt occurs, indicating that an inferior process has terminated.
In some cases, however, the superior cannot do additional processing until either a specific process or all of its inferior processes have completed execution. If this is the case, the superior process can execute the WFORK% (Wait Process) monitor call. This call blocks the superior until one or all of its inferiors have terminated.
The WFORK% monitor call accepts one argument in AC1, the handle of the desired process. This handle can be .FHINF (-4) to block the superior until all inferiors terminate, but cannot be a handle on a superior process.
After execution of the WFORK% monitor call, control returns to the user's program at the instruction following the call, when the specified process or all of the inferior processes terminate. If an error occurs, it generates a software interrupt, which the program can process via the software interrupt system.
5.9 Inferior process status
The superior process can obtain the status of one of its inferiors by executing the RFSTS% (Read Process Status) monitor call. This call returns the status and PC words of the given inferior process.
The short form of the RFSTS% monitor call accepts one argument in AC1, the handle of the desired process. This handle cannot refer to a superior process or to more than one process. The long form accepts two argument words: flags,, process handle in AC1 and the address of the status return block in AC2. In the long form, RF%LNG (bit 0) is set in AC1 and bits 1-17 are unused (must be zero).
After execution of the short form of the RFSTS% call, control returns to the user's program at the instruction following the call. If the RFSTS% call is successful, AC1 contains the status word of the given process and AC2 contains the PC word. The status word is shown in Table 5-6.
| Bit | Symbol | Meaning | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | RF%FRZ | The process is suspended (that is, frozen). If this bit is not on, the process is not suspended. | |||||||||||||||||||||||||||
| 1-17 | RF%STS | The status of the process.
| |||||||||||||||||||||||||||
| 18-35 | RF%SIC | The channel number on which an interrupt occurred, which the process was not prepared to handle (see process status code .RFFPT above). |
The RFSTS% call returns with -1 (fullword) in AC3 if the specified handle is assigned but refers to a deleted process. The call generates an illegal instruction interrupt if the handle is unassigned.
In the long form of the RFSTS% monitor call, RF%LNG is set in AC1 and AC2 contains the address of a status-return block. On the return, AC1 and AC2 are not modified. The status-return block is described in Table 5-7.
5-7| Word | Symbol | Meaning | ||||||
|---|---|---|---|---|---|---|---|---|
| 0 | .RFCNT | Count of words returned in this block in the left half, and count of maximum number of words to return in right half (including this word). The right half of this word is specified by the user. | ||||||
| 1 | .RFPSW | Process status word. This word has the same format as AC1 on a return from a short call. If a valid, but unassigned, process handle was specified in AC1, then this word contains -1 and no other words are returned. | ||||||
| 2 | .RFPFL | Process PC flags. These are the same flags returned in AC2 on a short call. | ||||||
| 3 | .RFPPC | Process PC. This is the address; no flags are returned in this word. | ||||||
| 4 | .RFSFL | Status flag word.
Flags:
|
If an error occurs during execution of the RFSTS% call, a software interrupt is generated which the program can process via the software interrupt system.
5.10 Process communication
A superior process can communicate with its inferiors by sharing the same pages of memory. This sharing is accomplished with the CFORK% (bit CR%MAP) or the PMAP% monitor call. When the superior executes either of these calls, both the superior and the inferior share the same pages. Changes made to the shared pages by either process will be seen by the other process.
Alternatively, processes can communicate via the software interrupt system. The superior process can cause a software interrupt to be generated in an inferior process by executing the IIC% (Initiate Interrupt on Channel) monitor call. For this type of communication to occur, the inferior's interrupt channels must be activated and its interrupt system enabled.
The IIC% monitor call accepts two words of arguments in AC1 and AC2. The handle of the process to receive the interrupt is given in the right half of AC1. AC2 contains a 36-bit word, with each bit representing one of the 36 software channels. If a bit is on in AC2, a software interrupt is initiated on the corresponding channel. For example, if bit 5 is on in AC2, an interrupt is initiated on channel 5.
Thus,
| AC1: | process handle in the right half |
| AC2: | 36-bit word, with bit n on to initiate a software interrupt on channel n |
The process handle given cannot refer to a superior process or to more than one process.
After execution of the IIC% call, control returns to the user's program at the instruction following the call. If an error occurs, it generates a software interrupt which the program can process via the software interrupt system.
5.11 Deleting an inferior process
A process is deleted from the job structure when the superior process executes the KFORK% (Kill Process) monitor call. When a process is deleted, its address space, its handle, and any JFNs acquired by the process are released. If the process being deleted has processes inferior to it, the inferiors are also deleted. For example, in the structure:
---------------
| Process A |
---------------
|
|
---------------
| Process B |
---------------
|
|
---------------
| Process C |
---------------
if process A deletes process B by executing a KFORK% call, process C is also deleted.
The KFORK% monitor call accepts one argument in the right half of AC1, the handle of the process to be deleted. This handle cannot refer to a superior process, to more than one process (for example, .FHINF), or to the process executing the call (that is, .FHSLF). The RESET% monitor call is used to reinitialize the current process; refer to Section 2.6.1.
After execution of the KFORK% call, control returns to the user's program at the instruction following the call. If an error occurs, a software interrupt is generated, which the program can process via the software interrupt system.
5.12 Process examples
Example 1
This program creates an inferior process to provide timing interrupts.
TITLE TIMINT - AN INFERIOR PROCESS PROVIDING TIMING INTERRUPTS
SEARCH MONSYM
SEARCH MACSYM
.REQUIRE SYS:MACREL
STDAC. ;DEFINE STANDARD ACS
START: RESET% ;RELEASE FILES, ETC.
MOVE P,[IOWD PDLSIZ,PDL] ;INITIALIZE STACK
MOVX T1,CR%MAP ;MAKE NEW PROCESS SHARE THIS
;PROCESS'S MEMORY
CFORK% ;CREATE A NEW PROCESS
EJSHLT ;UNEXPECTED FATAL ERROR
MOVEM T1,HANDLE ;SAVE PROCESS HANDLE
;HERE TO START THE INFERIOR PROCESS
STPROC: SETZB T4,FLAG ;INITIALIZE COUNTER AND FLAG
MOVE T1,HANDLE ;GET PROCESS HANDLE
MOVEI T2,SLEEP ;GET ADDRESS TO START PROCESS
SFORK% ;START THE NEW PROCESS
EJSHLT ;UNEXPECTED FATAL ERROR
; MAIN PROCESSING LOOP
LOOP: AOS T4 ;INCREMENT COUNTER
SKIPN FLAG ;HAS TIME ELAPSED YET?
JRST LOOP ;NO, GO DO MORE PROCESSING
; HERE WHEN LOWER PROCESS HAS INTERRUPTED
TMSG <
Counter has reached > ;OUTPUT FIRST PART OF MESSAGE
MOVX T1,.PRIOU ;GET PRIMARY OUTPUT DESIGNATOR
MOVE T2,T4 ;GET VALUE OF COUNTER
MOVEI T3,^D10 ;USE DECIMAL RADIX
NOUT% ;OUTPUT CURRENT COUNTER VALUE
EJSERR ;PRINT ERROR MESSAGE AND CONTINUE
TMSG <
> ;MOVE TO A NEW LINE
JRST STPROC ;CONTINUE COUNTING
; PROGRAM PERFORMED BY INFERIOR PROCESS TO WAIT FOR ONE-HALF MINUTE
SLEEP: MOVX T1,^D30*^D1000 ;ONE-HALF MINUTE IN MILLISECONDS
DISMS% ;WAIT FOR SPECIFIED TIME
SETOM FLAG ;TELL SUPERIOR TIME HAS ELAPSED
HALTF% ;FINISHED
; CONSTANTS AND STORAGE
PDLSIZ==50 ;SIZE OF THE STACK
PDL: BLOCK PDLSIZ ;STACK
HANDLE: BLOCK 1 ;INFERIOR PROCESS HANDLE
FLAG: BLOCK 1 ;INTERRUPT FLAG
END START
Example 2
This program illustrates how an inferior process may be used as a source of timer interrupts. The main program increments a counter. It has an inferior process running for the sole purpose of timing 10 second intervals. Each time the inferior process has timed 10 seconds, it stops and interrupts the main program. The main program then reports how many more times it has incremented the counter since the last 10 second interrupt.
TITLE TRMINT - FORK TERMINATION INTERRUPTS
SEARCH MONSYM
SEARCH MACSYM
.REQUIRE SYS:MACREL
STDAC. ;DEFINE STANDARD ACS
START: RESET% ;RELEASE FILES, ETC.
MOVE P,[IOWD PDLSIZ,PDL] ;INITIALIZE STACK
; SET UP THE INTERRUPT SYSTEM
MOVX T1,.FHSLF ;GET PROCESS HANDLE FOR THIS FORK
MOVE T2,[LEVTAB,,CHNTAB] ;GET TABLE ADDRESSES
SIR% ;SET INTERRUPT TABLE ADDRESSES
EJSHLT ;UNEXPECTED FATAL ERROR
MOVX T2,1B<.ICIFT> ;GET PROCESS TERMINATION CHANNEL BIT
AIC% ;ACTIVATE PROCESS TERMINATION CHANNEL
EJSHLT ;UNEXPECTED FATAL ERROR
EIR% ;ENABLE INTERRUPT SYSTEM
EJSHLT ;UNEXPECTED FATAL ERROR
; CREATE AND START THE INFERIOR PROCESS
MOVX T1,CR%MAP+CR%ST+SLEEP
CFORK% ;CREATE AND START TIMER AT SLEEP
EJSHLT ;UNEXPECTED FATAL ERROR
MOVEM T1,HANDLE ;SAVE PROCESS HANDLE
;INITIALIZE THE COUNTER
STPROC: SETZB T4,OLDT4 ;CLEAR COUNTER
;MAIN LOOP OF THE PROGRAM WHICH JUST KEEPS COUNTING. (REAL
;APPLICATION WOULD PRESUMABLY HAVE A MORE USEFUL MAIN PROGRAM.)
LOOP: AOJA T4,LOOP ;JUST KEEP INCREMENTING
; HERE WHEN LOWER PROCESS HAS INTERRUPTED
PROINT: MOVEM P,IACS+P ;SAVE STACK POINTER
MOVEI P,IACS ;MAKE POINTER FOR REST OF ACS
BLT P,IACS+CX ;SAVE REST OF ACS
MOVE P,IACS+P ;RESTORE P
TMSG <NUMBER OF COUNTS: >
MOVX T1,.PRIOU ;GET PRIMARY OUTPUT DESIGNATOR
EXCH T4,OLDT4 ;SAVE NEW COUNTER VALUE
SUB T4,OLDT4 ;FIND NUMBER OF COUNTS SINCE LAST TIME
MOVM T2,T4 ;MAKE IT POSITIVE
MOVEI T3,^D10 ;USE DECIMAL RADIX
NOUT% ;OUTPUT CURRENT COUNTER VALUE
EJSERR ;PRINT ERROR MESSAGE AND CONTINUE
TMSG <
> ;MOVE TO A NEW LINE
MOVE T1,HANDLE ;GET PROCESS HANDLE
MOVEI T2,SLEEP ;GET ADDRESS TO START PROCESS
SFORK% ;START THE NEW PROCESS
EJSHLT ;UNEXPECTED FATAL ERROR
MOVSI P,IACS ;GET POINTER TO SAVED ACS
BLT P,P ;RESTORE SAVED ACS
DEBRK% ;DISMISS INTERRUPT
;THE FOLLOWING IS EXECUTED AS A LOWER PROCESS TO DO THE
;TIMING. IT SLEEPS FOR 10 SECONDS AND THEN STOPS.
SLEEP: MOVX T1,^D10*^D1000 ;10 SECONDS IN MILLISECONDS
DISMS% ;SLEEP
HALTF% ;STOP AND INTERRUPT THE MAIN PROGRAM
; CONSTANTS AND STORAGE
PDLSIZ==50 ;SIZE OF THE STACK
PDL: BLOCK PDLSIZ ;STACK
CHNTAB: REPEAT ^D19,<EXP 0> ;CHANNELS 0-18 ARE NOT USED
1,,PROINT ;LEVEL 1 PROCESS TERMINATION CHANNEL
REPEAT ^D15,<EXP 0> ;REMAINING CHANNELS ARE NOT USED
LEVTAB: RETPC1 ;RETURN PC STORED AT RETPC1 FOR
;LEVEL 1
0 ;LEVEL 2 NOT USED
0 ;LEVEL 3 NOT USED
HANDLE: BLOCK 1 ;INFERIOR PROCESS HANDLE
RETPC1: BLOCK 1 ;RETURN PC STORED HERE ON INTERRUPTS
OLDT4: BLOCK 1 ;HOLDS TIMER VALUE AT LAST INTERRUPT
IACS: BLOCK 20 ;STORAGE FOR ACS DURING INTERRUPTS
END START
Example 3
This program creates an inferior process which waits until a line has been typed on the terminal.
TITLE FRKDOC - AN INFERIOR PROCESS WAITS UNTIL A LINE IS TYPED
SEARCH MONSYM
SEARCH MACSYM
.REQUIRE SYS:MACREL
STDAC. ;DEFINE STANDARD ACS
START: RESET% ;RELEASE FILES, ETC.
MOVE P,[IOWD PDLSIZ,PDL] ;INITIALIZE STACK
MOVX T1,CR%MAP ;MAKE NEW PROCESS SHARE THIS
;PROCESS'S MEMORY
CFORK% ;CREATE A NEW PROCESS
EJSHLT ;UNEXPECTED FATAL ERROR
SETZB T4,FLAG ;INITIALIZE COUNTER AND FLAG
MOVEI T2,GETCOM ;GET ADDRESS TO START PROCESS
SFORK% ;START THE NEW PROCESS
EJSHLT ;UNEXPECTED FATAL ERROR
; MAIN PROCESSING LOOP
LOOP: AOS T4 ;INCREMENT COUNTER
SKIPN FLAG ;HAS TIME ELAPSED YET?
JRST LOOP ;NO, GO DO MORE PROCESSING
; HERE WHEN INFERIOR PROCESS HAS INPUT A LINE OF TEXT
TMSG <
Counter has reached > ;OUTPUT FIRST PART OF MESSAGE
MOVX T1,.PRIOU ;GET PRIMARY OUTPUT DESIGNATOR
MOVE T2,T4 ;GET VALUE OF COUNTER
MOVEI T3,^D10 ;USE DECIMAL RADIX
NOUT% ;OUTPUT CURRENT COUNTER VALUE
EJSERR ;PRINT ERROR MESSAGE AND CONTINUE
TMSG <
Echo Check: > ;OUTPUT FIRST PART OF MESSAGE
HRROI T1,BUFFER ;GET POINTER TO BUFFER
PSOUT% ;OUTPUT TEXT JUST ENTERED
HALTF% ;STOP
JRST START ;IN CASE PROGRAM CONTINUED
; PROGRAM PERFORMED BY INFERIOR PROCESS TO INPUT A LINE OF TEXT
GETCOM: HRROI T1,BUFFER ;GET POINTER TO TEXT BUFFER
MOVEI T2,BUFSIZ*5 ;GET COUNT OF MAX # OF CHARACTERS
SETZM T3 ;NO RETYPE BUFFER
RDTTY% ;READ A LINE FROM THE TERMINAL
EJSERR ;UNEXPECTED ERROR
SETOM FLAG ;TELL SUPERIOR TIME HAS ELAPSED
HALTF% ;FINISHED
; CONSTANTS AND STORAGE
PDLSIZ==50 ;SIZE OF THE STACK
PDL: BLOCK PDLSIZ ;STACK
BUFSIZ==50 ;BUFFER SIZE
BUFFER: BLOCK BUFSIZ
FLAG: BLOCK 1 ;INTERRUPT FLAG
END START