LINUX TIPS AND TRICKS --- September 29, 2000

Published by ITworld.com, the IT problem-solving network
http://www.itworld.com/newsletters

*********************************************************************

Introducing Signals
by Danny Kalev

This week, I will introduce the basic concepts of signals -- a 
fundamental concept for Linux system programming. 

Processes operate within their address space and cannot communicate 
directly with other processes unless they use some sort of interprocess 
communication. Signaling, one such mechanism, enables a process to send 
a signal to another process and receive incoming signals. Once the 
receiving process has handled the signal, it resumes its execution flow 
from the point of interruption.

There are two types of signals: synchronous and asynchronous. A 
synchronous signal occurs as a direct result of the process's 
instruction flow. If, for example, a process attempts to access an 
illegal memory address, it receives a synchronous signal indicating a 
segmentation fault. Such signals are often called "traps". By contrast, 
external sources issue asynchronous signals, such as executing the 
kill() or sigsend() system calls from another process. Asynchronous 
signals are also called "interrupts".

A unique number containing a matching symbolic constant beginning with 
SIG identifies every signal. For instance, the "abort" signal has the 
associated constant SIGABRT, which equals 6. For every signal, Linux 
defines a default action, or disposition, that executes when the signal 
occurs. The four possible dispositions are:

    Exit - forces the process to exit
    Core - forces the process to exit and create a core file
    Stop - stops the process
    Ignore - ignores the signal

A process can override the default disposition for most signals by 
providing explicit handlers for them. All threads within a process share 
the same signal dispositions though; hence, you can't define individual 
dispositions for different threads within the same process.

A process can temporarily block incoming signals. If a signal is sent to 
a process that has blocked incoming signals, the signal remains pending 
until it's unblocked or the disposition is changed to "ignore". 

Signals originate from various sources. Pressing the keys Ctrl-Z on the 
keyboard generates the SIGTSTP signal, a parent process is notified when 
a child process changes its status through signals, accessing an illegal 
memory address generates the SIGSEGV signal and so on. When a signal is 
set, a bit in a special data structure associated with the process is 
set. The kernel periodically polls these data structures, and if one of 
the signal bits is set, a predefined action takes place, according to 
the signal's disposition in the process that received it.

Next week:  Killing a Process.

Resources

On the Qt 
Discover the object library behind KDE
http://www.itworld.com/jlw/lintpsnl/lw-2000-03/lw-03-penguin_7.html

Qt 2.x and Python 1.6 bind together well 
PyQt makes for easy GUI construction
http://www.itworld.com/jsw/lintpsnl/swol-05-2000/swol-05-qt_p.html

A primer on signals, Part 1 
Learn the ins and outs of implementing signals in Solaris
http://www.itworld.com/jsw/lintpsnl/swol-04-1999/swol-04-insidesolaris.html

************************************************************************ 

About the author
----------------
Danny Kalev is a system analyst and software engineer with more
than 10 years of experience, specializing in C++ and
object-oriented analysis and design on various platforms including
VMS, DOS, Windows, Unix, and Linux. His technical interests involve
code optimization, networking, and distributed computing. He is
also a member of the ANSI C++ standardization committee and the
author of ANSI/ISO C++ Professional Programmer's Handbook (Que,
1999). Contact him at linuxnl@excite.com.

*********************************************************************

CONTACTS

* For editorial comments, write Andrew Santosusso, Associate Editor, 
Newsletters at: andrew_santosusso@itworld.com
* For advertising information, write Dan Chupka, Account Executive at:
dan_chupka@itworld.com
* For recruitment advertising information, write Jamie Swartz, Eastern
Regional Sales Manager at: jamie_swartz@itworld.com or Paul Duthie,
Western Regional Sales Manager at: paul_duthie@itworld.com
* For all other inquiries, write Jodie Naze, Product Manager,
Newsletters at: jodie_naze@itworld.com

*********************************************************************

Copyright 2000 ITworld.com, Inc., All Rights Reserved.

http://www.itworld.com
