JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
STREAMS Programming Guide
search filter icon
search icon

Document Information


Part I Application Programming Interface

1.  Overview of STREAMS

2.  STREAMS Application-Level Components

3.  STREAMS Application-Level Mechanisms

Message Handling

Modifying Messages

Message Types

Control of Stream Head Processing

Read Options

Write Options

Message Queueing and Priorities

Controlling Data Flow and Priorities

Accessing the Service Provider

Closing the Service Provider

Sending Data to the Service Provider

Receiving Data

Input and Output Polling

Synchronous Input and Output

Asynchronous Input and Output

signal Message

Extended Signals

Stream as a Controlling Terminal

Job Control

Allocation and Deallocation of Streams

Hungup Streams

Hangup Signals

Accessing the Controlling Terminal

4.  Application Access to the STREAMS Driver and Module Interfaces

5.  STREAMS Administration

6.  Pipes and Queues

Part II Kernel Interface

7.  STREAMS Framework - Kernel Level

8.  STREAMS Kernel-Level Mechanisms

9.  STREAMS Drivers

10.  STREAMS Modules

11.  Configuring STREAMS Drivers and Modules

12.  Multithreaded STREAMS

13.  STREAMS Multiplex Drivers

Part III Advanced Topics

14.  Debugging STREAMS-based Applications

Part IV Appendixes

A.  Message Types

B.  Kernel Utility Interface Summary

C.  STREAMS-Based Terminal Subsystem




Stream as a Controlling Terminal

The controlling terminal can receive signals and send signals. If a foreground process group has the stream as a controlling terminal stream, drivers and modules can use M_SIG messages to send signals to processes.

Job Control

An overview of Job Control is provided here because it interacts with the STREAMS-based terminal subsystem. You can obtain more information on Job Control from the following manual pages: exit(2), getpgid(2), getpgrp(2), getsid(2), kill(2), setpgid(2), setpgrp(2), setsid(2), sigaction(2), signal(3C), sigsend(2), termios(3C), waitid(2), and termio(7I).

Job Control breaks a login session into smaller units called jobs. Each job consists of one or more related and cooperating processes. The foreground job, is given complete access to the controlling terminal. The other background jobs are denied read access to the controlling terminal and given conditional write and ioctl(2) access to it. The user can stop the executing job and resume the stopped job either in the foreground or in the background.

Under Job Control, background jobs do not receive events generated by the terminal and are not informed with a hangup indication when the controlling process exits. Background jobs that linger after the login session has been dissolved are prevented from further access to the controlling terminal, and do not interfere with the creation of new login sessions.

The following list defines terms associated with Job Control:

Background process group

A process group that is a member of a session that established a connection with a controlling terminal and is not the foreground process group.

Controlling process

A session leader that established a connection to a controlling terminal.

Controlling terminal

A terminal that is associated with a session. Each session can have at most one controlling terminal associated with it, and a controlling terminal can be associated with at most one session. Certain input sequences from the controlling terminal cause signals to be sent to the process groups in the session associated with the controlling terminal.

Foreground process group

Each session that establishes a connection with a controlling terminal distinguishes one process group of the session as a foreground process group. The foreground process group has certain privileges that are denied to background process groups when accessing its controlling terminal.

Orphaned process group

A process group in which the parent of every member in the group is either a member of the group, or is not a member of the process group's session.

Process group

Each process in the system is a member of a process group that is identified by a process group ID. Any process that is not a process group leader can create a new process group and become its leader. Any process that is not a process group leader can join an existing process group that shares the same session as the process. A newly created process joins the process group of its creator.

Process group leader

A process whose process ID is the same as its process group ID.

Process group lifetime

A time period that begins when a process group is created by its process group leader and ends when the last process that is a member in the group leaves the group.

Process ID

A positive integer that uniquely identifies each process in the system. A process ID cannot be reused by the system until the process lifetime, process group lifetime, and session lifetime end for any process ID, process group ID, and session ID sharing that value.

Process lifetime

A period that begins when the process is forked and ends after the process exits, when its termination has been acknowledged by its parent process.


Each process group is a member of a session that is identified by a session ID.

Session ID

A positive integer that uniquely identifies each session in the system. It is the same as the process ID of its session leader (POSIX).

Session leader

A process whose session ID is the same as its process and process group ID.

Session lifetime

A period that begins when the session is created by its session leader and ends when the lifetime of the last process group that is a member of the session ends.

The following signals manage Job Control: (see also signal(3C)) :


Sent to a stopped process to continue it.


Sent to a process to stop it. This signal cannot be caught or ignored.


Sent to a process to stop it. It is typically used when a user requests to stop the foreground process.


Sent to a background process to stop it when it attempts to read from the controlling terminal.


Sent to a background process to stop it when a user attempts to write to or modify the controlling terminal.

A session can be allocated a controlling terminal. For every allocated controlling terminal, Job Control elevates one process group in the controlling process's session to the status of foreground process group. The remaining process groups in the controlling process's session are background process groups. A controlling terminal gives a user the ability to control execution of jobs within the session. Controlling terminals are critical in Job Control. A user can cause the foreground job to stop by typing a predefined key on the controlling terminal. A user can inhibit access to the controlling terminal by background jobs. Background jobs that attempt to access a terminal that has been so restricted is sent a signal that typically causes the job to stop. (See Accessing the Controlling Terminal.)

Job Control requires support from a line-discipline module on the controlling terminal's stream. The TCSETA, TCSETAW, and TCSETAF commands of termio(7I) allow a process to set the following line discipline values relevant to Job Control:

SUSP character

A user-defined character that, when typed, causes the line discipline module to request that the stream head send a SIGTSTP signal to the foreground process, which by default stops the members of that group. If the value of SUSP is zero, the SIGTSTP signal is not sent, and the SUSP character is disabled.


If TOSTOP is set, background processes are inhibited from writing to their controlling terminal. A line discipline module must record the SUSP suspend character and notify the stream head when the user has typed it, and record the state of the TOSTOP bit and notify the stream head when the user has changed it.

Allocation and Deallocation of Streams

A stream is allocated as a controlling terminal for a session if it:

Hungup Streams

When a stream head receives a hangup message from a device or module, it is marked as hung up. A stream that is marked as hung up is allowed to be reopened by its session leader if it is allocated as a controlling terminal, and by any process if it is not allocated as a controlling terminal. This way, the hangup error can be cleared without forcing all file descriptors to be closed first.

If the reopen is successful, the hangup condition is cleared.

Hangup Signals

When the SIGHUP signal is generated by a hangup message instead of a signal message, the signal is sent to the controlling process instead of the foreground process group. The allocation and deallocation of controlling terminals to a session is the responsibility of that process group.

Accessing the Controlling Terminal

If a process attempts to access its controlling terminal after it has been deallocated, access is denied. If the process is not holding or ignoring SIGHUP, it is sent a SIGHUP signal. Otherwise, the access fails with an EIO error.

Members of background process groups have limited access to their controlling terminals: