• Streams: two-way channels used for communication among processes and with human users through various communications devices.

• Child process support: the creation of, communication with, and deletion of child processes controlled by a parent process. The children need not run on the same node as the parent process.

• Server and client processes: the ability of a process (the server) to establish a service with a global, unique name, and the ability of a client process to establish communication with that service, given the service's name. A single server may provide more than one service. Server and client processes may run on different nodes.

• Scheduled coroutines: cooperating “featherweight” tasks running within a single MAINSAIL process that perform independent I/O functions in parallel.

3.1. Stream Features

On some platforms, advanced STREAMS provides the ability to control processes and communicate with other processes using server/client communication. If advanced STREAMS is supported, the ability to schedule advanced STREAMS may also be supported.

Appendix C summarizes the current status of support and implementation of STREAMS on the current MAINSAIL platforms. Programs that must run on systems where only some STREAMS features are supported must use the runtime tests provided to determine which features are available. They must then adapt to the environment as best they can.

3.1.2. The Basic TTY Stream

POINTER($stream) $tty;

is automatically opened to the controlling terminal.

The TTY stream may be half-duplex, in which case I/O may be restricted to a line at a time. This minimal implementation is sufficient to write, e.g., a KERMIT server, but not a KERMIT client. The minimal STREAMS capabilities provided for half-duplex TTY streams are no more than what the MAINSAIL language currently guarantees for terminal I/O on half-duplex systems.

The minimal STREAMS capabilities for full-duplex TTY streams are more than what MAINSAIL terminal I/O promises, but similar to what the full-duplex MAINSAIL display MODULEs assume. Thus, full-duplex TTY streams can be used to read and write single characters at a time or groups of characters, optionally with echo turned off.

3.1.3. Reading Interrupt Characters from the TTY

3.1.6. Writing a BREAK on TTY Streams

A program may determine whether scheduling applies to the TTY stream on the host system, that is, whether $tty can participate in scheduled I/O activities along with other streams, by the test $isScheduled($tty). If not, I/O to $tty must be assumed to block.

3.1.9. Catching Keyboard Interrupts

If $enableInterrupts succeeds, the exception $keyboardInterruptExcpt is raised whenever the Scheduler gets control and discovers an interrupt that has not previously been observed. This exception is raised in the coroutine that most recently called $enableInterrupts.

If the $tty is scheduled, i.e., $isScheduled($tty) is TRUE, the exception $keyboardInterruptExcpt can be raised while the program is waiting for TTY input. Otherwise, interrupts that occur during TTY input cause the exception to be raised the next time that the Scheduler is invoked following the TTY input.

3.1.10. Server/Client Communication

3.1.11. Child Process Creation

Child processes may be categorized as either cooperating or noncooperating.

A child process that knows it is being invoked by a parent and that uses an agreed-upon communication protocol is called a cooperating child process. Typically, a cooperating child process uses its $tty for error messages and debugging and a secondary stream (available as the STREAMS system variable $parent) for communication with the parent process.

A child process that does not know that it is being run from a parent is called a noncooperating child process. All communication with noncooperating children takes place through the child's TTY.

Some systems support the ability to create noncooperating child processes with a $tty that has all of the semantics normally associated with a $tty, including echo and line editing on input. On such systems the stream MODULE called PTYPRO is available.

Limits on the ability to run noncooperating general child processes through PTYPRO are system-dependent. On some systems, the PTYPRO stream is half-duplex, capable only of line-at-a-time I/O. The results of running a display editor in such a child process would be less than satisfactory!

3.1.12. The System Shell as a Child Process

The STREAMS system macro $systemSupportsScheduling tells whether the host system supports scheduling of advanced STREAMS. This support is independent of whether the system supports scheduling on TTY streams. Thus, there are four possible levels of scheduling possible on a given system:

IF $systemSupportsScheduling AND $isScheduled($tty) THEN
    # the system supports scheduling on all streams
EF $systemSupportsScheduling AND NOT $isScheduled($tty) THEN
    # the system supports scheduling of advanced STREAMS but
    # not $tty
EF $isScheduled($tty) AND NOT $systemSupportsScheduling THEN
    # the system supports scheduling of only $tty
EL  # the system does not support scheduling at all

The STREAMS system macro $systemSupportsTimeout tells whether the host system supports the ability to use timeouts on scheduled streams. If the TTY can be scheduled and $systemSupportsTimeout is TRUE, timed input may also be performed on the TTY. If $systemSupportsTimeout is FALSE, timeout values are ignored.

Currently, all systems that support scheduled streams also support timeouts.

3.2. Stream Types

• TTY streams

• socket (interprocess communication or IPC) streams

• memory streams

• PTY streams

TTY streams allow the program to communicate with a terminal. The terminal may be either a screen and a keyboard or a serial line (e.g., RS-232). For historical reasons that are not likely to change soon, TTY streams have special modes, limitations, and job control side effects.

Socket streams provide conceptually simple, unencumbered communication between processes.

Memory streams are a special kind of stream for internal communication between coroutines of the same process. They are created in pairs.

PTY streams are used to communicate with a child process that thinks it is communicating with a real terminal. The parent, which is typically a shell or a windowing system, passes on the child's output, read from the PTY, to a terminal or window. The parent passes keystrokes to the child by writing to the PTY.

Other stream types may be implemented in the future.

3.3. Automatic Scheduling of Stream I/O

Whenever any coroutine calls a stream I/O PROCEDURE, the Scheduler coroutine is resumed to decide what to do next. The original caller coroutine is resumed by the Scheduler only when its requested I/O is ready, i.e., when the I/O can be performed without blocking. In this way, the program runs much the way it would if each of its coroutines were run as a separate process under a multiprocess operating system, or as separate programs on two different computers.

Chapter 8 describes the use of stream scheduling for implementing multitasking programs.

3.4. Loose Coupling of STREAMS to MAINSAIL

In the current release of MAINSAIL, the stream I/O facilities are “loosely coupled” with the MAINSAIL runtime system. In particular, unless special steps are taken, normal TTY I/O through cmdFile and logFile, the file TTY, ttyRead and ttyWrite, and $timeout are performed independently of the stream Scheduler and therefore block.

Eventually it may be that all I/O to the file TTY (e.g., the default cmdFile and logFile) will go through the $tty stream, at least on systems where STREAMS is installed. The PROCEDUREs ttyRead, ttyWrite, and ttycWrite may also eventually go through the $tty stream. Should this “strong coupling” be implemented, the PROCEDURE $timeout will work through the Scheduler if $systemSupportsTimeout is TRUE.

In the meantime, to aid programs that wish to make output to the file TTY be scheduled, the device MODULE NTTY is supplied. Output to a file opened through NTTY goes through $tty. In particular, if cmdFile and logFile are reopened through NTTY, any I/O to the terminal through them is scheduled, including error messages reported by errMsg. Example 3–2 shows how a program can arrange to use the NTTY device MODULE in place of the file TTY.