Unix and Linux System Dependencies

The OSDI and DP4 Terminal Manager communicate through pipes, thus:

• stdin (file number 0) is replaced by a result pipe, the same pipe is also allocated to file number 4.
• A control pipe is allocated to file number 3
• The terminal manager sends commands (in response to actions from the application such as selecting a POD etc.) to DIP3 using the control pipe. It also sends a command for every character it want to read in input functions.
• The terminal manager gets the result of the commands, for example device status information and error information by reads on the result pipe. Keyboard reads are done using file handle 0, and other results are read from file handle 4 (though this should not matter to the OSDI).

A Unix OSDI manages communication by creating separate child processes. The first process (which we shall denote P0) forks to create a child process P1 and then goes into a loop calling inp_task(). P1 forks to create P2 and then goes into a loop waiting for messages; it is P1 which calls inp_start(), inp_stop() and the prn_xxx() functions. P2 forks again to run the application and then goes into a loop reading an intermediate pipe and copying its contents to the message queue.

If only keyboard input is required then inp_task() should consist of a loop which reads the keyboard and calls inp_avail().

If input from other devices is required, inp_start() may fork off processes to read the various devices; any such child process may call inp_avail() as required. Similarly prn_print() may fork off processes to perform asynchronous printing and such child processes may call prn_complete(). If the inp_task() process is not required (as in the example code) it should not call exit() as it is the immediate child of the shell which started the application; instead it should call pause() which will cause it to wait until the other processes terminate when it will receive SIGCLD.

The inp_idle() function is not required; for compatibility with the other operating systems a dummy function which does nothing is supplied.

Note that the global variables inp_device, prn_device and so on are only updated by the code of the P1 process and so inp_task() cannot rely on their values.

Note on Linux

The DP4 terminal manager detects whether an application is being run under an OSDI by testing the status of file handles 3 and 4. Prior to 4.522 only file handle 3 was tested. On Linux this prevented DP4 programs from being run inside the make utiltity, because on Linux this utility runs DP4 applications with file handle 3 belonging to what appears to be a pipe. Testing both handles allows DP4 programs to run from within make, but not from within a nested make that was called by make. This is really a bug in Linux as a well behaved make utility would not allow child processes to inherit its file handles. A work around for this problem is to define the environment variable DP4NODIP3, which prevents the terminal manager looking for DIP3.