The ProcessMgr class manages a game loop. It may be the primary or an auxiliary game loop. Details of creating and managing the game loop thread are handled by this class.
Each ProcessMgr maintains a list of Processes whose update methods are called during each iteration of the game loop. For any Actor, all Processes that own that Actor must run within the same ProcessMgr. The details of this are handled by the engine and need not concern clients. But it is important to be aware of the ownership relationships between your Processes and Actors, and to try to avoid cases where single Processes own many Actors, or single Actors are owned by many processes. These two cases are the most difficult to load balance effectively and can make concurrency impossible within Gaffer.
Each ProcessMgr has a private instance of EventMgr which handles event passing within the ProcessMgr. Events can travel from one ProcessMgr to another if they have appropriate event flags, and if the event doesn't get handled within the initiating ProcessMgr. An example is the "shutdown" event, which must propogate through the entire system.
Chain of Siblings
Each ProcessMgr has a sibling. Through this relationship, the ProcessMgr objects running in the system form a singly linked list. The sibling is the only ProcessMgr that it can communicate with directly. Communication between two ProcessMgr requires thread synchronization and is thus avoided as much as possible. But when events do pass from one ProcessMgr to another the fact that this communication is one way and to only one other ProcessMgr keeps lock waits down to a minimum.
Gaffer attempts to load balance Processes optimally across ProcessMgrs. Each ProcessMgr periodically sends out diagnositic events describing its current load. When a new Process is created, the ProcessMgr in which it is created can decide to add it to its process list, or send it to another ProcessMgr that has a lower load.