dcsimg

Erik Troan Archive

A Walk Through Some of the Most Popular Linux Signals
My last two columns talked about the Linux (and POSIX) signal API and how to use it to write programs that handle signals. Now that you understand what signals are and how they can be manipulated by your application, I want to talk about some of the most commonly used signals. For each signal, I'll describe when the signal is sent, what the default action is, and how most programs handle it. Remember that the type of action a particular signal should invoke is mostly a convention. Users will expect a certain behavior, but programs can do pretty much whatever they like.
How to Make Use of Signals When Writing Linux Applications
Let me start off with a correction (sigh). Last month I described the difference between slow and fast system calls and then described select() as a slow system call. That was incorrect. Since select() takes a timeout value, it always returns in a predictable amount of time, so it's considered a fast system call.
The Ins and Outs of Signal Processing
One of the nice things about being a programmer is that you get to work in a simplified world. Computers are designed and built to do exactly what you tell them to do (even if it's not what you mean), and to do the same thing over and over again, yielding nice, reproducible results. The reason programs are so well behaved is that they normally execute sequentially. One step follows another, and nothing happens in between, so your data will stay the same as it was when you last touched it. Your program's flow becomes obvious and any bugs that you may have are reproducible.
Multiplexed I/0 with poll()
In the last column, I talked about how to read and write from multiple file descriptors seemingly simultaneously with the select() function call. Using multiplexed I/O lets programs block while waiting for notification that some file descriptors are ready for reading or writing.
Multiplexed I/O
Linux programs often need to access more than one file at the same time. This can require a bit of coordination -- or multiplexing -- of the I/O. Under normal circumstances, the order in which different files get accessed by a program is determined by a simple algorithm. For example, the cat command employs the following algorithm to achieve this:
Blocking and Non-Blocking I/0
In previous columns, we've looked at the Linux file model, and discussed many of the Linux system calls. This month, we're going to talk a bit more about the semantics of the read() and write() system calls. Remember that read() and write() have very similar prototypes:
Open Files and Inodes
Last month, I wrote about Linux's file access API. For this month's column, I'm gong to talk about some of the other important file-related system calls, and touch on how the kernel file implementation affects the system call interface.
The Linux File Access Primitives
One of the most important abstractions of the POSIX API is the file. While nearly all operating systems provide files for permanent storage, all versions of UNIX provide access to most system resources through the file abstraction.
Introduction to System Calls
Before anyone can write software for a particular operating system, they must first understand the programming interfaces the system provides. Many of Linux's APIs are defined by the POSIX standard; other APIs which Linux provides were originally introduced by groups like the X Consortium or by other operating systems. At the core of all of these APIs is Linux's system call interface, which every other system API is built around.