Table of Contents
The Massiv defines a concept of a central management of all global objects (i.e. singleton objects that are accessible globally from both the Core and the application, often called Core subsystems) represented by the Global static class. In addition to the Global class there is System class that can be used to control the Core in a more abstract way, without the need for digging into internal Core subsystems. A few words on this topic were already written in Section 15.1, “Overview”.
Global class serves as a repository for all global objects defined in the Core. It holds references to them and and provides methods (one per each object) to access them. Moreover it publishes an interface for logging messages in a simplier way (therefore there is no need for using the logger explicitly).
![[Warning]](images/warning.png) | Warning |
|---|---|
Whenever a global object needs be accessed, corresponding reference must be obtained from the Global class and must not be kept by the caller. This allows to replace global object instances at run-time. | |
Global objects are created and properly registered to the repository by System::initialize() method. An attempt to access an unregistered object results in a run-time error (assert).
The following list summarizes global objects registered to the Global class. Note that not all the global objects can be utilized by the application directly. In fact some objects are actually private to the Core and must not be used by the application at all! However the list doesn't contain such "banned" objects.
Names of the methods, used for accessing particular objects, are quite straightforward. For example, to get a reference to ThreadManager you have to use the Global::thread_manager() method. For other objects the naming principle is the same.
You can find more information about all of the objects in the Massiv Core Reference Guide. Moreover, at some of them there is a link to yet another information source.
AccountManager
Manages client's account creation (in cooperation with the data service.
See also Section 14.3, “Account Object”.
ClassManager
Registers all known managed classes supported by the local node and keeps metaobjects for them. Each class is assigned an unique class type id, which can be transmitted over the network and is not platform specific (unlike standard C++ type info).
See also Section 12.2.1, “Obtaining a MetaObject”.
CriticalSectionManager
Manages critical sections creating.
See also Section 17.5, “Worker Threads” or the Massiv Core Reference Guide, module Threads.
DataManager
Manages data objects and allows for dynamic (on-the-fly) data downloads while a player is already playing the game. It also enables substitutions of unavailable data by a more general one that has already been downloaded.
See also Chapter 24, Data Service.
Logger
Logger enables making logs at run-time providing a possibility to sort messages according to several-criteria filters and send them to various destinations.
See also Chapter 20, Logger Library.
Object manager is responsible for local object management. It pushes the simulation forward.
PathManager
Enables to get filesystem paths to various Massiv-specific or system directories, such as log, data, source_data (see Chapter 24, Data Service), archive, work or login directory.
See also the Massiv Core Reference Guide.
Registry
A hierarchical database that stores variables that may come either from configuration files, from various statistics or may be created for other reasons at run-time.
See also Chapter 19, Registry.
ReplicaManager
Replica manager monitors updates of replicas. An user can register a callback that will be invoked everytime the specified replicas are updated.
See also the Massiv Core Reference Guide.
SemaphoreManager
Manages semaphore instantiations.
See also Section 17.5, “Worker Threads”.
ThreadManager
Manages worker threads.
See also Section 17.5, “Worker Threads”.
VolumeManager
Manages a virtual file system that provides a single interface for accessing streams on the native file system as well as a set of mounted Massiv-specific volumes (such as Volume or CompactVolume images).
See also Chapter 21, Massiv Filesystem.
The Global logging methods are shortcuts for similar methods provided directly by the Logger.
The most useful methods are log_debug, log_info, log_warning and log_error, each having facility, priority and message parameters (except for the log_error method that has only the facility and message parameters, because the priority is automatically the highest possible. See Chapter 20, Logger Library to get better idea what is the difference between the methods and what the parameters stand for.
The following example shows a typical code that logs some non-trivial message:
int line_number = ...; ... std::ostringstream s; s << "syntax error at line \"" << line_number << "\""; Global::log_warning( Status::FACILITY_REGISTRY, Status::PRIORITY_HIGH, s.str() ); |