From Wikipedia, the free encyclopedia

In computer programming, a callback is executable code that is passed as an argument to other code. It allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer.

A callback is often back on the level of the original caller.

However, while technically accurate, this might not be the most illustrative explanation. Think of it as an "In case of fire, break glass" subroutine. Many computer programs tend to be written such that they expect a certain set of possibilities at any given moment. If "Thing That Was Expected", then "Do something", otherwise, "Do something else." is a common theme. However, there are many situations in which events (such as fire) could happen at any time. Rather than checking for them at each possible step ("Thing that was expected OR Things are on fire"), it is easier to have a system which detects a number of events, and will call the appropriate function upon said event (this also keeps us from having to write programs like "Thing that was expected OR Things are on fire OR Nuclear meltdown OR alien invasion OR the dead rising from the grave OR...etc., etc.) Instead, a callback routine is a sort of insurance policy. If zombies attack, call this function. If the user moves their mouse over an icon, call HighlightIcon, and so forth.

Usually, there is a framework in which a series of events (some condition is met) in which the running framework (be it a generic library or unique to the program) will call a registered chunk of code based on some pre-registered function (typically, a handle or a function pointer) The events may be anything from user input (such as mouse or keyboard input), network activity (callbacks are frequently used as message handlers for new network sessions) or an internal operating system event (such as a POSIX-style signal) The concept is to develop a piece of code that can be registered within some framework (be it a GUI toolkit, network library, etc.) that will serve as the handler upon the condition stated at registration. How the flow of control is passed between the underlying framework and the registered callback function is specific to the framework itself.

In another common scenario, the callback is first registered and later called asynchronously.

[edit] Motivation

To understand the motivation for using callbacks, consider the problem of a network server. At any given point in time, it may have an internal state machine that is currently at a point in which it is dealing with one very specific communication session, not necessarily expecting new participants. As a host, it could be dealing with all the name exchange and handshakes and pleasantries, but no real way of dealing with the next dinner party guest that walks through the door. One way to deal with this is for this server to live by a state machine in which it rejects new connections until the current one is dealt with...not very robust (What if the other end goes away unexpectedly?) and not very scalable (Would you really want to make other clients wait (or more likely, keep retrying to connect) until it's their turn?) Instead, it's easier to have some sort of management process that spins off a new thread (or process) to deal with the new connection. Rather than writing programs that keep dealing with all of the possible resource contention problems that could come of this, or all of the details involved in socket code (your desired platform may be more straight-forward than others, but one of your design goals may be cross-platform compatibility), many have opted to use more generic frameworks that will handle such details in exchange for providing a reference such that the underlying framework can call it if the registered event occurs.

[edit] Example

The following code in C demonstrates the use of callbacks for the specific case of dealing with a POSIX-style signal (in this case SIGUSR1).

#include <stdio.h>
#include <signal.h>
void * sig(int signum)
{
printf("Received signal number %d!\n", signum);
}
int main(int argc, char *argv[])
{
signal(SIGUSR1,&sig);
while(1){};
return 0;
}

The while loop will keep this example from doing anything interesting, but it will give you plenty of time to send a signal to this process. (If you're on a unix-like system, try a "kill -USR1 <pid>" to the process ID associated with this sample program. No matter how or when you send it, the callback should respond.)

[edit] Implementation

The form of a callback varies among programming languages.

• C and C++ allow function pointers as arguments to other functions.
• Several programming languages (though especially functional programming languages such as Scheme or ML) allow closures, a generalization of function pointers, as arguments to other functions.
• Several programming languages, especially interpreted languages, allow one to pass the name of a function A as a parameter to a function B and have B call A by means of eval.
• In object-oriented programming languages, a call can accept an object that implements some abstract interface, without specifying in detail how the object should do so. The programmer who implements that object may use the interface's methods exclusively for application-specific code. Such objects are effectively a bundle of callbacks, plus the data they need to manipulate. They are useful in implementing various design patterns like Visitor, Observer, and Strategy.
• C++ allows objects to provide their own implementation of the function call operation. The Standard Template Library accepts these objects (called functors), as well as function pointers, as parameters to various polymorphic algorithms
• C# .NET Framework provides a type-safe encapsulating reference, a 'delegate', to manage function pointers. These can be used for callback operations.
• Perl supports subroutine references.^[1][2]
• Some systems have built-in programming languages to support extension and adaptation. These languages provide callbacks without the need for separate software development tools.

[edit] Special cases

Callback functions are also frequently used as a means to handle exceptions arising within the low level function, as a way to enable side-effects in response to some condition, or as a way to gather operational statistics in the course of a larger computation. Interrupt handlers in an operating system respond to hardware conditions, signal handlers of a process are triggered by the operating system, and event handlers process the asynchronous input a program receives.

A pure callback function is one which is purely functional (always returns the same value given the same inputs) and free of observable side-effects. Some uses of callbacks require pure callback functions to operate correctly.

A special case of a callback is called a predicate callback, or just predicate for short. This is a pure callback function which accepts a single input value and returns a Boolean value. These types of callbacks are useful for filtering collections of values by some condition.

[edit] See also

• Signals and slots
• libsigc++, a callback library for C++
• Implicit invocation
• User exit
• Inversion of control

[edit] External links

• Style Case Study #2: Generic Callbacks
• C++ Callback Solution
• Basic Instincts: Implementing Callback Notifications Using Delegates
• Implement Script Callback Framework in ASP.NET
• Implement callback routines in Java

[edit] References