Tuesday, December 26, 2006

Managing MySQL on Solaris 10: Part 4: Solaris Doors and Signals

The Solaris Doors API, originally developed as a core part of the Spring Operating System, is basically nothing more than an RPC mechanism. The Solaris Doors, which are made visible as door descriptors (standard UNIX file descriptors) , relies heavily on threads and allows us to call procedures between processes on the same system. A door client makes a call to a door server which has a thread that is awaken, which passed the scheduling control directly to the thread in the door server. The control and the response is passed back to the calling thread when the door server has completed executing the request.

A door is made visible to other applications by attaching an already existing door descriptor to an existing regular file in the UNIX file system.

Solaris supports the following doors functions

When events like segmentation violation (illegal address references) and floating point exceptions occur, a process or a thread within a process needs to be interrupted. The UNIX signal facility provides for handling such exceptions by notifying a process or a thread of such events.

The signals can be either synchronous or asynchronous depending on the reason and source of the signal.

The segmentation violation and folating point exceptions are examples of synchronous signals, which typically arise as "hardware trap" conditions. The executing instruction stream can cause synchronous signals. These signals are also sometimes refered to as traps because it can cause "a trap into a kernel trap handler."

On the other hand, asynchronous signals such as job control signals and signals to kill a process, arise from external events that may or may not be related to the current instruction stream. These signals are sometimes known as interrupts.

All signals have unique names beginning with SIG. Each signal also has a signal number.

A default disposition (out of four possible ones) is also defined for all possible signals, namely exit, core, stop and ignore.

A process can describe how it is going to handle such signals except when it receives SIGKILL and SIGSTOP since the disposition for these signals cannot be changed. For instance, a process can ignore such signals, catch them, or invoke the default action of a signal. Since Solaris is multithreaded, a signal can be directed to a specific thread within a process. We can also specify which threads will block (mask) which signals.

For more information on signals, read the article "A Primer on Signals in the Solaris OS." If you want more detailed information, get the book, "Advanced Programming in the UNIX Environment" by W. Richard Stevens.


No comments: