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

• door_bind(3DOOR) – bind or unbind the current thread with the door server pool
• door_call(3DOOR) – invoke the function associated with a door descriptor
• door_create(3DOOR) – create a door descriptor
• door_cred(3DOOR) – return credential information associated with the client
• door_info(3DOOR) – return information associated with a door descriptor
• door_return(3DOOR) – return from a door invocation
• door_revoke(3DOOR) – revoke access to a door descriptor
• door_server_create(3DOOR) – specify an alternative door server thread creation function
• door_ucred(3DOOR) – return credential information associated with the client
• door_unbind(3DOOR) – bind or unbind the current thread with the door server pool

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.

References:

• Namefs and Solaris Doors for Linux: The implementation of the Solaris Doors API on Linux is called Doors/ Linux and is currently in Alpha.
• An Implementation of the Solaris Doors API for Linux: A paper by Jason Lango describing the implementation of the Solaris Doors API on Linux. The paper discusses "the relative performance improvements that doors can offer versus some of the standard UNIX IPC mechanisms".
• Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, Second Edition
  
• Doors: Wikipedia
• Signal: Wikipedia
  
• Real-time Library Functions:
  
• A Primer on Signals in the Solaris: An article by Jim Mauro detailing the "Ins and Outs of Implementing Signals in the Solaris Operating Environment."