Home ›

The Linux Signals Handling Model

Issue 73

From Issue #73
May 2000

May 01, 2000  By Moshe Bar
 in
Communication is the key to healthy relationships between threads and the kernel; these are the signals they use to communicate.
Signals and Interrupts, A Perfect Couple

Signals can be sent from system calls, interrupts and bottom-half handlers (see sidebar) alike; there is no difference. In other words, the Linux signal queue is interrupt-safe, as strange and recursive as that sounds, so it's fairly flexible.

Bottom-Half Handlers

An interesting signal-delivery case, however, is on SMP. Imagine a thread is executing on one processor, and it gets an asynchronous event (e.g., synchronous socket I/O signal) from an IRQ handler (or another process) on another CPU. In that case, we send a cross-CPU message to the running process, so there is no latency in signal delivery. (The speed of cross-CPU delivery is about five microseconds on a Pentium II 350MHz.)

Conclusions

Once again, we notice how Linux is actually the technology leader in important kernel aspects such as scheduling, interrupt handling and signals handling. This also proves the conjecture that the Linux developer community is collectively more capable and more resourceful than any private corporation's R&D department could ever be.

Resources

Moshe Bar (moshe@moelabs.com) is an Israeli system administrator and OS researcher, who started learning UNIX on a PDP-11 with AT&T UNIX Release 6 back in 1981. He holds an M.Sc. in computer science. Visit Moshe's web site at http://www.moelabs.com/.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I have One Question about the

Zafar's picture
Submitted by Zafar (not verified) on Mon, 09/27/2010 - 09:10.

I have One Question about the Usage of SIGNAL() and SIGACTION() so which function shall I Use. Is the use of traditional SIGNAL() is a disadvantage.

"Asynchronous signals are

Ling's picture
Submitted by Ling (not verified) on Tue, 08/10/2010 - 15:52.

"Asynchronous signals are delivered to the first thread found not blocking the signal." The only solution I found so far is to create a thread to process all signals, and mask the rest of the threads.

This makes the signal pretty useless on Android, as we don't have control of how threads are created, and the system might use other signals.

I have read some suggestion and working solution in the kernel to deliver the signal to the originated thread, instead of random thread.

I wonder if the latest kernel is supporting this, or if anyone has solution for this.

Thanks!

Signal Handling

Anonymous's picture
Submitted by Anonymous (not verified) on Tue, 09/18/2007 - 11:55.

Is there a pictorial representation of the signal handling process in Linux to help visualize the switch between the user space and kernel space?

What does 'reliable' mean? What happens if a signal is unreliabl

Ming's picture
Submitted by Ming (not verified) on Tue, 06/12/2007 - 13:00.

"Implementation of correct and reliable signals has been in place for many years now ... reliable signals require the use of the newer sigaction interface" - What is the definition of 'reliable signals'? Are there some signals reliable and some not, in the same implementation? Or are there reliable implementations in which all signals are reliable, and unreliable implementations where all signals are unreliable?
And I have a question that is not answered in all the papers and books I have read so far: what happens if a signal arrives when a previous one (of the same type) is being handled in a signal catching function?

RE: What does 'reliable' mean?

Anonymous's picture
Submitted by Anonymous (not verified) on Wed, 11/07/2007 - 04:15.

I trust reliable is referred to in the sense that some functions makes the entire signaling handling reliable, e.g. 'sigaction' may block signals and set a new signal handler in one atomic swoop, as to eliminate the potential race condition.
As to your last question, if the signal is not blocked and a new instance is generated in the midst of the processing of the last one, then the signal handler must be re-entrant. IMHO, the best method is to block the signal on entering the signal handler. It will be automatically restored on exit. On old UNIX versions, once a signal handler is invoked, the signal handling is reverted to default. If a new signal instance comes along, it will be treated the default way, most often terminating the process.

Table 1 HTML lacks tag

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 07/07/2006 - 09:00.

Table 1 HTMl page lacks start tag for the table, making the page unrenderable, even if the article is dated in year 2000.

start tag.

Keith Daniels's picture
Submitted by Keith Daniels on Fri, 07/07/2006 - 10:49.

Thanks for catching that. I will fix it ASAP

Webmaster - Linux Journal

"I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone."
-- Bjarne Stroustrup

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions