Twisted System Events

One of the key features of the Twisted Python web framework is the ability to define reactors that react to asynchronous events. One concept of the the Twisted reactor is the system event. The ReactorBase class is inherited from all reactor types in Twisted, as the name suggests. It is this class that provides all other reactors with a system event processing implementation.

An event, in the context of the Twisted reactor system, has three phases, or states. These states are "before", "during", and "after". What this provides for developers is a means to conceptually organize triggers that are executed when a specific event is fired. The "before" state should execute triggers that are supposed to verify certain data, or perform setup tasks. Anything that would be considered a pre-condition is executed here. The "during" state is overall goal of the event. Triggers that are executed in this state should do the heavy processing. Conceptually, this is the main reason a trigger was registered to execute with the specified event type in the first place. Finally, the "after" state executes triggers that should perform post-condition testing, or clean-up type tasks.

Illustrated below are the various states that a Twisted system event will go through during its' lifetime. The transitions between states are quite straightforward. When there are no more triggers to execute for the current state, the next state is entered.



Event triggers are registered with specific event types by invoking the ReactorBase.addSystemEventTrigger() method. This method accepts an event state, callable, and event type parameters. The callable can be any callable Python object.

The type of event in which triggers can be registered to can be anything. The event type is only the key for a stored event instance. The _ThreePhaseEvent class is instantiated if not already part on the reactor. That is, if a trigger has already been registered for the same event type, that means an event instance has been created. The _ThreePhaseEvent instance for each event type is responsible for executing all event triggers in the correct order. Using the Twisted system event functionality means that dependencies between event states may be used to achieve desired functionality.

Twisted Application Reactors

At the heart of any Twisted Python application lies one or more reactors. Reactors, as the name suggests, react to events. Whether the event is local or remote, the reactor is the core concept in Twisted concerned with invoking behavior in response to these events.

The Twisted application module defines an application Reactor class. This class is extended by actual reactor implementations that may be used within Twisted applications. Reactors that are available for installation may be enumerated over by using the getReactorTypes() function. The use of this function is illustrated below.

#Example; Enumerating reactor types.

#Import the required function.
from twisted.application.reactors import getReactorTypes

#Main.
if __name__=="__main__":

  #Iterate over the reactor types.
  for i in getReactorTypes():
    
      #Display reactor information.
      print i.shortName
      print i.description,"\n"

The design of the Reactor class is really straightforward. The Reactor is an extensibility mechanism of the Twisted framework. That is, it can be installed and used as necessary. The Reactor class provides the IPlugin and the IReactorInstaller interfaces. The Reactor class and the interfaces it provides are illustrated below.

As you can see, the Reactor class has three simple attributes; shortName, moduleName, and description. The moduleName is really important for installing the reactor. It tells Twisted where the actual code for the reactor can be found.

The getReactorTypes() is useful for providing choices to the user. This would actually make more sense as a configuration option for advanced users such as an administrator.