By : syn1988@sdf.lonestar.org
UNIX signals provide a mechanism for notifying processes of system events. Each event has it's own signal number, which is usually referred to by
a symbolic constant such as "SIGTERM". There are two kinds of system events :
1. Asynchronous notifications (user-defined)
For instance, a user can send the interrupt signal "SIGINT" to a foreground process by pressing the interrupt keycode (such as CTRL+C) at the terminal.
2. Synchronous errors or exceptions
For instance, the kernel sends the signal "SIGSEGV" to a process when it accesses a memory location at an illegal address.
The POSIX srandard defines about 20 different signals, two of which are user-definable and may be used as a primitive mechanism for communication and
synchronization among processes in "User Mode". In general, a process may react to a signal delivery in two possible ways :
- Ignore the signal
- Asynchronously execute a specified procedure (the signal handler)
If the processes does not specify one of these alternatives, the kernel performs a default action that depends on the signal number. the five possible
default actions are :
- Terminate the process
- Write the execution context and the contents of the address space in a file (core dump) and terminate the process
- Ignore the signal
- Suspend the process
- Resume the processes execution, if it was stopped
Kernel signal is rather elaborate since the POSIX semantics allows processes to temporarily block signals. Moreover, the "SIGKILL" and "SIGSTOP" signals
cannot be directly handled by the process or ignored.
AT&T UNIX System V introduced other kinds of interprocess communication among processes in "User Mode", which have been adopted by many UNIX kernels:
Semaphores, Message Queues, and Shared Memory. They are collectively known as System V IPC.
The kernel implements these constructs as IPC resources. A process acquires a resource by invoking a :
- shmget() --> setting shared memory
- semget() --> setting user-defined semaphore
- msgget() --> setting user-defined message-queue
system call. Just like this, IPC resources are persistent: they must be explicitly deallocated by the creator process, by the current owner, or by
superuser process.