One major difference between Windows and Unix-based operating systems
is the support for handling programmer-defined signals. Although the
Standard C library provides some basic support for signal handling [2],
it is not enough for the programmer who needs signals mainly for
implementing interprocess communication. Indeed, the absence of such a
mechanism in the context of Windows makes the asynchronous
communication between the processes (threads) difficult and requires
the usage of special data structures, like events, and the creation of
dedicated threads that poll continuously the status of some conditions
[6]. In this artice, I introduce SignalsLib, a library for the support
of signal handling on Win32 programming platforms. The heart of the
library is a device driver that provides the mechanisms needed to cause
a signal handler in a target process to execute asynchronously, even if
the target process is not in an alertable state.
This article provides a general overview of signal handling, an outline
of the support Windows provides for signals and some basic mechanisms,
the design and implementation of the library and driver, performance
measurements of the implemented mechanisms, an API that is exported to
the programmer, and possible uses and extensions of this work.
Overview of Signals
Signals are a mechanism for informing processes about asynchronous
events. The basic idea is that each distinct signal has an associated
integer code, and any process can register a handler (a callback
function) for any signal (by specifying its integer code). When one
process sends a specific signal to another process that has registered
a handler for that signal, the target process will stop whatever it is
doing and execute the handler function registered for that signal.
The signal mechanism is analogous to interrupt handling, in that a
signal interrupts whatever code is currently executing in the target
process. Just like interrupt handlers, signal handlers require careful
coding — ordinary code must not access the same data as signal handlers
unless they both use synchronization primitives to avoid corrupting
each other’s work. Signals provide simple and convenient interprocess
communication. Common traditional uses include: notifying a service
that it should rotate its log files, notifying a parent process that
the child process has completed initialization and is ready to start
doing useful work, notifying a process that it should temporarily pause
operation, notifying a process that it should perform a clean shutdown
as soon as possible, and so on.
Each signal is associated with an action that will be executed by the
kernel on behalf of the process that has received the signal. For most
signals, the default action is the termination of the process, although
a process can require some alternative action from the system. The
various possible alternatives are:
1. Ignore the signal. In this case, the process is not informed about the signal.
2. Restore the default signal action.
3. Execute a specific signal-handling function. This is the case in
which the process wants to perform some custom action when a specific
signal arrives. The process registers a special function that gets
invoked asynchronously when the associated signal occurs. After the
signal handling function returns, whatever code it interrupted will
resume executing.
Windows Support for Signals
Win32 offers a very specific kind of signal support in the form of SetConsoleCtrlHandler().
This function lets a console process catch a variety of
system-generated signals (the user pressed Ctrl-C, the user is logging
off, etc.). It does not offer any programmer-defined signals, nor does
it offer any interprocess communication — it is strictly a means for
the operating system to notify a process of a few specific events.
The only other signal-like mechanism that Windows offers is structured
exception handling. However, Standard C requires support for the
well-known signal()/raise() Unix functions and a constrained number of signals [2]. signal() sets the signal-handling function to be called for a given signal. raise()
sends a specific signal to the current process, invoking either
whatever handler was registered for that signal, or else the default
action associated with that signal. Again, these signals are not
extensible, and they are local to a given process. (Standard C defines
no function for sending a signal to another process.)
Instead of signals, Windows supports APCs (Asynchronous Procedure
Calls). An APC is a kernel-defined control object that represents a
procedure that is called asynchronously. APCs have the following
features [7]:
1. An APC always runs in a specific thread context.
2. An APC runs at OS predetermined times.
3. APCs can preempt the currently running thread.
4. APC routines can themselves be preempted.
There are three different types of APCs in the kernel [2,3]:
User-mode APCs. User-mode APCs are, by default, disabled; that
is, they are queued to the user-mode thread, but are not executed,
except at well-defined points in the program. Specifically, they can be
executed only when an application has either called a wait service and
has enabled alerts to occur or, called the test-alert service.
Normal kernel-mode APCs. These are much like user-mode APCs,
except that they are executable by default. That is, they are enabled
except when the thread is already executing a kernel-mode APC or is
inside a critical code section.
Special kernel-mode APCs. These cannot be blocked, except by
running at a raised IRQL (interrupt request level). Special kernel-mode
APCs are executed at IRQL APC_LEVEL, in kernel mode. They are
used by the system to force a thread to execute a procedure in a
thread’s context. A special kernel-mode APC can preempt the execution
of a normal kernel-mode APC.
The Win32 API [4] provides QueueUserAPC(), which allows
an application to queue an APC object to a thread. The queuing of an
APC is a request for the thread to call the APC function. When a
user-mode APC is queued, the thread is not directed to call the APC
function unless it is in an alertable state. Unfortunately, a thread
enters an alertable state only by using one of the following Win32 API
functions: SleepEx(), SignalObjectAndWait(), WaitForSingleObjectEx(), WaitForMultipleObjectEx(), or MsgWaitForMultipleObjectsEx().
In kernel mode [1], the programmer initializes an APC object using KeInitializeApc(),
defining the target thread, one kernel-mode and one user-mode callback
routine, the type of the APC (kernel or user), and finally an argument
to these two functions. Next, the APC is queued (KeInsertQueueApc()) to the target thread and can be executed without having the thread be in an alertable state.
The SignalsLib Interface
The library provides the necessary structures and mechanisms for
elementary support of signal handling exporting an appropriate
interface to the programmer. During the building process, the user can
define the option for support per thread or the usage of a global table
of signal handlers.
signals.h (Listing 1) defines the available
signals, from zero to MAX_SIGNALS-1. This header file also defines
the two functions that make up the interface to the signals library.
SetSignalHandler() sets a handler for a given signal. It returns zero for failure, or non-zero for success.
SendSignalToThread() sends a signal to the specified thread. You
must specify the handle of the thread you want to signal, as well as
the signal (integer code) you want to send. It returns zero for
failure, or non-zero for success.
testapp.c (Listing 2) demonstrates how
to use the signals library. This application creates a thread that sets a
handler for a specific signal, and the main thread then sends that signal
to the thread, resulting in the execution of the installed signal handler.
Of course, the driver must be installed into the system and loaded, or else
an appropriate message is printed, when the library’s DLLMain()
is executed.
Design and Implementation
SignalsLib consists of a DLL and a kernel-mode device driver. The DLL
provides a user-mode interface for applications, while the device
driver is necessary for accessing the kernel-mode functions used to
queue a kernel-mode APC to the target thread. The calling application
simply makes calls to SetSignalHandler() and SendSignalToThread(), however — the DLL hides all the details of communicating with the device driver.
SetSignalHandler() is simple — it just stores the supplied function
pointer in the appropriate position of a global array of signal handlers.
When a signal actually occurs, the internal routine SignalsDriverRoutine()
will get invoked and use this global array to determine what signal handler
to call. Both of these routines are in signals.c (Listing
3).
SendSignalToThread() is where the DLL communicates with the device driver. DllMain() obtains a handle for the device driver when the DLL is first loaded and releases that handle when the DLL is unloaded. SendSignalToThread() uses that handle in a call to DeviceIoControl() to pass the device driver a SIGINFO structure:
typedef struct _SIGINFO
{
HANDLE hThread; /* target thread */
ULONG SigNo; /* signal number */
ULONG SigFunc; /* address of DriverRoutine */
} SIGINFO, *PSIGINFO;
Note that SigFunc is not the address of an individual signal handler, but rather the address of SignalsDriverRoutine(), a function in the DLL that looks up and invokes the correct signal handler.
When SendSignalToThread() passes this information to DeviceIoControl(),
it will cause the driver’s interrupt service routine to be invoked. The
main source code for the driver is in sigdrv.c (Listing
4). The driver’s interrupt service routine invokes SigDriverSendTheSignal(),
which is responsible for queuing an appropriate kernel-mode APC to the target
thread. SigDriverSendTheSignal() takes a pointer to the ETHREAD
data structure [2] of the target thread. It calls KeInitializeApc()
to initialize a kernel-mode APC and then calls KeInsertQueueApc() to
queue that APC for the target thread.
The queued APC contains a pointer to another function in sigdrv.c
(Listing 4): UserApcCallBack(). This function
will get invoked in user mode and passed the SIGINFO structure. UserApcCallBack()
uses the information in SIGINFO to invoke the DLL function SignalsDriverRoutine(),
which will in turn look up and invoke the signal handler associated with the
given signal.
Performance Evaluation
The choice of normal rather than special kernel-mode APCs has to do
with the desired functionality, not with performance. If it’s important
that the signal handler be preempted if another signal occurs, then you
should use special kernel-mode APCs rather than normal kernel-mode APCs.
The APC mechanism performs extremely well; the signal handler is
invoked as soon as the target thread is scheduled, typically within a
few microseconds. It is important to mention that kernel-mode APCs
achieve immediate signal delivery, independently of the system load
(number of threads that run on the system). You might be able to reduce
the response time further via thread priorities. For example, SendSignalToThread() could increase the priority of the target thread.
Conclusions
I’ve implemented the basic mechanisms of user-defined signals, mainly
in order to enable asynchronous communication between threads of the
same or different Win32 applications. The resulting DLL and device
driver combination provides the two major functions for signal
handling, similar to the signal() and kill() Unix system calls, and for signals similar to SIGUSR1 and SIGUSR2.
A possible extension of this library includes the implementation of the handlers for some Unix signals, like SIGSTOP, SIGCONT, and SIGTERM,
and the support of the POSIX standard. It would also be interesting to
integrate these mechanisms with the Standard C library. The library
assists in implementing the pthread_kill() POSIX function and
makes easier the development of applications that require notification
mechanisms between their threads in user mode or from kernel to user
mode, as the device driver needs only to know the address of the driver
routine. Although the POSIX standard defines global signal handlers for
all the threads of an application, the library can easily support
per-thread signal handlers by using thread local storage; for
simplicity, that was not done in this version.
To keep the code simple for publication, this implementation assumes
that all participating processes will share a single instance of signals.dll. More specifically, SendSignalToThread() always passes the address of SignalsDriverRoutine()
(in the context of the calling process) to the device driver, but the
device driver will attempt to use that address in the context of the
target process (which will likely be different). That will be
disastrous if the target process loaded signals.dll at a different address than the calling process did. If a particular process cannot load signals.dll
at its default address, you can always select another default address
until you find one that does not collide with anything already loaded.
You could solve the problem more elegantly by revising the interface so
that the device driver has enough information to locate the correct
callback address for a given thread.
Finally, an alternative implementation, which is also not presented here, is based on user-mode APCs. SendSignalToThread() uses the Win32’s QueueUserAPC()
and next, through a kernel-mode device driver, manages to set the
target thread in alertable state. This is possible by setting to one
the memory address that corresponds to 0x4a bytes offset [5] from the base address of the ETHREAD data structure [2].
References
[1] E. N. Dekker and J. M. Newcomer. Developing Windows NT Device Drivers: A Programmer’s Handbook (Addison-Wesley, 1999).
[2] Microsoft Corporation. Microsoft Developer Network Library, msdn.microsoft.com/library.
[3] D. A. Solomon. Inside Windows NT, Second Edition (Microsoft Press, 1998).
[4] J. Ritcher. Advanced Windows: The Professional Developer’s Guide to the Win32 API for Windows NT 4.0 and Windows 95 (Microsoft Press, 1995).
[5] www.cmkrnl.com/arc-userapc.html
[6] www.microsoft.com/msj/0799/nerd/nerd0709.html
[7] www.osr.com/insider/1998/apc.html
[8] Microsoft Visual Studio\VC98\CRT\SRC\WINSIG.C
Panagiotis Hadjidoukas is a postgraduate student at High
Performance Information Systems Laboratory, Department of Computer
Engineering & Informatics, at the University of Patras in Greece.
You can reach him by email at peh@hpclab.ceid.upatras.gr or at the web
page of his laboratory at http://www.hpclab.ceid.upatras.gr.
