Blame | Last modification | View Log | RSS feed
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>liboop: How?</title><link rel="stylesheet" type="text/css" href="style.css"></head><body><h2>Overview of liboop.</h2><h4>The basic idea.</h4>Liboop is primarily an <em>interface definition</em>. It defines an interfacewhich components may use to request notification when an <em>event</em>(activity on a file descriptor, the real-time clock reaches a certain value,a particular signal is received) occurs. The component which owns the eventloop -- the component whose code is active when the system is idle --implements the interface; it is an <em>event source</em>. Components whichare interested in events register themselves with the event source; they are<em>event sinks</em>. Event sinks may themselves source other, higher-levelevents, but that is outside liboop's scope.<h4>Control flow.</h4>During initialization, the event source is created. At least one event sinkis also created, and registered with the event source. Once initializationcompletes, control is transferred to the event source, which (at its core)waits for events, usually using a system function like select() or poll().When an event occurs, the event source gives a <em>callback</em> to all theevent sinks which registered interest in that event.<p>During callbacks, the event sinks react to the event as appropriate (usuallyperforming some I/O, or at least modifying internal state). Event sinks forevents which are no longer relevant may be unregistered; new event sinks maybe registered for additional events. Each event sink, when it finishes,returns a value which tells the event source whether to continue processingevents or whether to terminate.<p>While the event source must be fully reentrant (registration and deregistrationmay, and indeed usually are, performed within the context of an event), eventsinks need not be; no event sink will be called while another event sink isactive.<p>If no event sink instructs the event source to terminate, the event sourcecontinues waiting for events. Otherwise, the event source returns to itscaller, which usually shuts down the system.<h4>The system event source.</h4>Liboop comes with a single "reference" implementation of an event source.This event source uses select() to dispatch events. Most programs builtaround liboop will probably use the standard system event source; legacyprograms with their own event loop, or programs with specialized needs mayimplement their own event source.<h4>Adapters.</h4>Liboop supports <em>adapters</em> to enable legacy components to use the liboopinterface. For example, many widget sets have their own event loop and theirown mechanism for registering callbacks on timeouts and file descriptoractivity; liboop uses <em>source adapters</em> that accept registration,register corresponding callbacks with the widget set's event loop, and routeevents appropriately. Such adapters let general-purpose liboop-basedcomponents work in an application based on that widget set.<p>Similarly, some components are designed to work in a non-blocking fashion, andthey might be used with a <em>sink adapter</em> to work with liboop. Anasynchronous DNS query package, for example, could work as a liboop sink thatultimately generates a higher-level "success" or "failure" callback to theinvoking routine.<h4>Code.</h4>Liboop's abstract event source interface is implemented as a structurecontaining C function pointers. These functions accept a pointer to thestructure as their first argument; sources are expected to include theirown data (in whatever format) with the core function pointers. Callbacksare also C function pointers, with "void *" arguments to pass data.<p>For more about the liboop interface, see the <a href="ref">reference</a>.<hr><a href="">liboop home</a></body></html>