<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-41F33130-7968-5016-9ACE-9E9F906118DB" xml:lang="en"><title>Using POSIX

Signals</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>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. </p>

<p>Signals are broadly classified into two types: </p>

<ul>

<li id="GUID-7C76E732-29E3-52C3-B757-D9755ABDE96F"><p> <b>Non-realtime signals

:</b> Non-realtime signals inform a process about system events. For example, <codeph>SIGINT</codeph> signifies

a user interrupt request (typically from a console). You can use the <codeph>SIGUSR1</codeph> and <codeph>SIGUSR2</codeph> signals

to define custom (user-defined) signals for your program. </p> </li>

<li id="GUID-30AC114F-EB7F-59C8-8E9D-03816D8E7A42"><p> <b>Real-time signals:</b> 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: </p> <ul>

<li id="GUID-9F352345-C466-52E2-AD82-491F7B0A8028"><p>They are delivered in

the order they are generated. </p> </li>

<li id="GUID-B386608A-1137-5ED0-B4FB-B78413ABA40E"><p>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. </p> </li>

</ul> <p>Real-time signals are in the range <codeph>SIGRTMIN</codeph> to <codeph>SIGRTMAX</codeph>.

You can refer to real-time signals using the notation <codeph>SIGRTMIN+n</codeph>.

For example, <codeph>SIGRTMIN</codeph>, <codeph>SIGRTMIN+1</codeph>, <codeph>SIGRTMIN+2</codeph>,

... <codeph>SIGRTMAX</codeph>. </p> </li>

</ul>

<p> <b>Note:</b> Real-time signals are subject to the same latency as non-realtime

signals in P.I.P.S. </p>

<p>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. </p>

</conbody></concept>