Event loop


In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler. The event loop is also sometimes referred to as the message dispatcher, message loop, message pump, or run loop.
The event-loop may be used in conjunction with a reactor, if the event provider follows the [|file interface], which can be selected or 'polled'. The event loop almost always operates asynchronously with the message originator.
When the event loop forms the central control flow construct of a program, as it often does, it may be termed the main loop or main event loop. This title is appropriate, because such an event loop is at the highest level of control within the program.

Message passing

Message pumps are said to 'pump' messages from the program's message queue into the program for processing. In the strictest sense, an event loop is one of the methods for implementing inter-process communication. In fact, message processing exists in many systems, including a kernel-level component of the Mach operating system. The event loop is a specific implementation technique of systems that use message passing.

Alternative designs

This approach is in contrast to a number of other alternatives:
Due to the predominance of graphical user interfaces, most modern applications feature a main loop. The get_next_message routine is typically provided by the operating system, and blocks until a message is available. Thus, the loop is only entered when there is something to process.
function main
initialize
while message != quit
message := get_next_message
process_message
end while
end function

File interface

Under Unix, the "everything is a file" paradigm naturally leads to a file-based event loop. Reading from and writing to files, inter-process communication, network communication, and device control are all achieved using file I/O, with the target identified by a file descriptor. The select and poll system calls allow a set of file descriptors to be monitored for a change of state, e.g. when data becomes available to be read.
For example, consider a program that reads from a continuously updated file and displays its contents in the X Window System, which communicates with clients over a socket :

main:
file_fd = open
x_fd = open_display
construct_interface
while changed_fds = select :
if file_fd in changed_fds:
data = read_from
append_to_display
send_repaint_message
if x_fd in changed_fds:
process_x_messages

Handling signals

One of the few things in Unix that does not conform to the file interface are asynchronous events. Signals are received in signal handlers, small, limited pieces of code that run while the rest of the task is suspended; if a signal is received and handled while the task is blocking in select, select will return early with EINTR; if a signal is received while the task is CPU bound, the task will be suspended between instructions until the signal handler returns.
Thus an obvious way to handle signals is for signal handlers to set a global flag and have the event loop check for the flag immediately before and after the select call; if it is set, handle the signal in the same manner as with events on file descriptors. Unfortunately, this gives rise to a race condition: if a signal arrives immediately between checking the flag and calling select, it will not be handled until select returns for some other reason.
The solution arrived at by POSIX is the pselect call, which is similar to select but takes an additional sigmask parameter, which describes a signal mask. This allows an application to mask signals in the main task, then remove the mask for the duration of the select call such that signal handlers are only called while the application is I/O bound. However, implementations of pselect have only recently become reliable; versions of Linux prior to 2.6.16 do not have a pselect system call, forcing glibc to emulate it via a method prone to the very same race condition pselect is intended to avoid.
An alternative, more portable solution, is to convert asynchronous events to file-based events using the self-pipe trick, where "a signal handler writes a byte to a pipe whose other end is monitored by select in the main program". In Linux kernel version 2.6.22, a new system call signalfd was added, which allows receiving signals via a special file descriptor.

Implementations

Windows applications

On the Microsoft Windows operating system, a process that interacts with the user must accept and react to incoming messages, which is almost inevitably done by a message loop in that process. In Windows, a message is equated to an event created and imposed upon the operating system. An event can be user interaction, network traffic, system processing, timer activity, inter-process communication, among others. For non-interactive, I/O only events, Windows has I/O completion ports. I/O completion port loops run separately from the Message loop, and do not interact with the Message loop out of the box.
The "heart" of most Win32 applications is the function, which calls in a loop. GetMessage blocks until a message, or "event", is received. After some optional processing, it will call , which dispatches the message to the relevant handler, also known as WindowProc. Normally, messages that have no special are dispatched to DefWindowProc, the default one. DispatchMessage calls the WindowProc of the HWND handle of the message.

Message ordering

More recent versions of Microsoft Windows guarantee to the programmer that messages will be delivered to an application's message loop in the order that they were perceived by the system and its peripherals. This guarantee is essential when considering the design consequences of multithreaded applications.
However, some messages have different rules, such as messages that are always received last, or messages with a different documented priority.

X Window System

Xlib event loop

applications using Xlib directly are built around the XNextEvent family of functions; XNextEvent blocks until an event appears on the event queue, whereupon the application processes it appropriately. The Xlib event loop only handles window system events; applications that need to be able to wait on other files and devices could construct their own event loop from primitives such as ConnectionNumber, but in practice tend to use multithreading.
Very few programs use Xlib directly. In the more common case, GUI toolkits based on Xlib usually support adding events. For example, toolkits based on Xt Intrinsics have XtAppAddInput and XtAppAddTimeout.
Please note that it is not safe to call Xlib functions from a signal handler, because the X application may have been interrupted in an arbitrary state, e.g. within XNextEvent. See for a solution for X11R5, X11R6 and Xt.

GLib event loop

The GLib event loop was originally created for use in GTK+ but is now used in non-GUI applications as well, such as D-Bus. The resource polled is the collection of file descriptors the application is interested in; the polling block will be interrupted if a signal arrives or a timeout expires. While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model.
Application libraries that are built on the GLib event loop include GStreamer and the asynchronous I/O methods of GnomeVFS, but GTK+ remains the most visible client library. Events from the windowing system are translated by GDK into GTK+ events and emitted as GLib signals on the application's widget objects.

macOS Core Foundation run loops

Exactly one CFRunLoop is allowed per thread, and arbitrarily many sources and observers can be attached. Sources then communicate with observers through the run loop, with it organising queueing and dispatch of messages.
The CFRunLoop is abstracted in Cocoa as an NSRunLoop, which allows any message to be queued for dispatch to any object.