A POSIX signal is a software equivalent of an interrupt. To handle a signal, a signal handler (which is a function) must be registered for that signal. On receipt of the signal, the operating system stops the process at its point of execution and executes the signal handler. The signal handler may terminate the process. If it does not, the OS resumes the process at the point it stopped. For this reason signals can be used as a form of IPC within a process or between two or more co-operating processes.
Signals are broadly classified into two types:
Non-realtime signals
: Non-realtime signals inform a process about system events. For example, SIGINT
signifies
a user interrupt request (typically from a console). You can use the SIGUSR1
and SIGUSR2
signals
to define custom (user-defined) signals for your program.
Real-time signals: As the name signifies, real-time signals inform a process about the occurrence of real-time events, such as high-resolution timer expiration, explicit signal delivery and asynchronous I/O completion. Real-time signals are different from non-realtime signals in the following ways:
They are delivered in the order they are generated.
When a real-time signal is delivered to a process and is blocked, first it is queued. Later, if the same real-time signal is delivered to the process again, it is queued once again. But for non-realtime signals, the signal is queued only once (when it is blocked) regardless of the number of times it is delivered to a process.
Real-time signals are in the range SIGRTMIN
to SIGRTMAX
.
You can refer to real-time signals using the notation SIGRTMIN+n
.
For example, SIGRTMIN
, SIGRTMIN+1
, SIGRTMIN+2
,
... SIGRTMAX
.
Note: Real-time signals are subject to the same latency as non-realtime signals in P.I.P.S.
The following topics describe how POSIX signals are emulated on the Symbian platform. They also describe how you can use these signals when you develop POSIX compliant applications or port POSIX-based applications onto the Symbian platform.