"Signal programming" is a term often used to refer to a computer program that functions primarily in response to signals or events generated by some change in state, or by user input. Nearly any part of a computer system, from a peripheral device to the operating system itself, can generate a signal that can be captured by an application and then processed. In many forms, signal programming resembles event-driven programming. Some of the most common uses for signal programming are with graphical user interfaces that respond to user input, network communications and low-level programs that capture and handle specific system signals.
A signal in computer programming can be defined as a message, an event or an interrupt, depending on its origin, the system architecture or even the preference of the programmer. In the broadest terms, it is an indicator that some state or piece of data has changed, and it sometimes is accompanied by additional information about the change that has occurred. The signal can be generated by the user when a key is pressed, from hardware such as a monitor when a vertical retrace occurs, or even from the operating system when something such as a page fault happens during memory allocation.
Within an application, signal programming can take on several types of architectures, but one of the most common is a listener or observer model. In this method, a piece of user-defined code can be passed in some way to a signal handler, usually within the operating system, which then calls that piece of code to process any signals that match what the function is seeking. The type of signal a function can handle often is determined by a variable known as a signal mask, so some signals are not passed to routines not designed to handle them.
A second type of signal programming involves having a program that implements a queue that accepts incoming signals. This queue is polled in the main execution loop of the program and the program reacts once a signal enters the queue. Each signal then can be logically sorted, handled, ignored or passed to another process.
Some difficulties can arise in signal programming when concurrent processes or multi-threaded applications are used. The complications can arise if, for instance, two separate threads are listening for signals generated by two separate user input devices, or from two network sockets. If two users simultaneously attempt to make a change to some data, then the program data could fall out of synchronization and appear differently to each user. Using a linear queue or implementing thread synchronization methods can help to prevent this situation.
