33
33
34
34
namespace NodeBase
35
35
{
36
+ // The purpose of modules is to avoid the type of totally unstructured
37
+ // main() that plagues so many systems.
38
+ //
36
39
// A module--the term as used here predates C++20 and is unrelated to its
37
40
// usage--consists of interrelated software that provides some logical
38
- // capability. It is implemented within its own namespace, which should
39
- // consist of a separate .h/.cpp pair for each major class. One of these
40
- // pairs is a Module subclass that is invoked during restarts. The term
41
+ // capability. The capability is often implemented in its own namespace
42
+ // and should have a separate .h/.cpp pair for each major class. One such
43
+ // pair is a Module subclass that is invoked during restarts. The term
41
44
// "restart" refers to both system initialization (when the executable is
42
45
// first launched) and reinitialization (to recover from a serious error).
43
46
//
@@ -51,7 +54,7 @@ namespace NodeBase
51
54
// private:
52
55
// SomeModule() : Module()
53
56
// {
54
- // // Modules 1 to N are the ones on which this module depends .
57
+ // // Modules 1 to N are the ones that this module requires .
55
58
// // Creating their singletons ensures that they will exist in
56
59
// // the module registry when the system initializes. Because
57
60
// // each module creates the modules on which it depends before
@@ -65,17 +68,27 @@ namespace NodeBase
65
68
// }
66
69
//
67
70
// ~SomeModule() = default;
71
+ //
72
+ // void Enable() override
73
+ // {
74
+ // // Enable the modules that this one requires, followed by this
75
+ // // module. This must be public if other modules require this
76
+ // // one. The outline is similar to the constructor.
77
+ // //
78
+ // Singleton<Module1>::Instance()->Enable();
79
+ // // ...
80
+ // Singleton<ModuleN>::Instance()->Enable();
81
+ // Module::Enable();
82
+ // }
83
+ //
68
84
// void Startup(RestartLevel level) override;
69
85
// void Shutdown(RestartLevel level) override;
70
86
// };
71
87
//
72
- // Later during initialization, ModuleRegistry::Startup handles most of
73
- // the system's initialization by invoking Startup on each module. The
74
- // Startup function initializes the data required by the module when
75
- // the system starts to run.
76
- //
77
- // The purpose of modules is to avoid the type of totally unstructured
78
- // main() that plagues so many systems.
88
+ // Later during initialization, ModuleRegistry::Startup handles most of the
89
+ // system's initialization by invoking Startup on each module that has been
90
+ // enabled (see the Enable function, below). A Startup function initializes
91
+ // the data required by its module when the system initializes or restarts.
79
92
//
80
93
class Module : public Immutable
81
94
{
@@ -95,8 +108,18 @@ class Module : public Immutable
95
108
static const ModuleId MaxId;
96
109
97
110
// Enables the module. Overridden to invoke this function on modules
98
- // that this one requires, after which this version must be invoked.
99
- // May only be invoked during a RestartReboot (first initialization).
111
+ // that this one requires (the same ones that its constructor created),
112
+ // after which this version must be invoked. Only invoked during a
113
+ // RestartReboot (initial launch), when NodeBase (the lowest layer)
114
+ // has initialized. This function is invoked on each module whose
115
+ // Symbol() appears in the configuration parameter OptionalModules,
116
+ // which in turn causes it to enable the modules that it requires.
117
+ // If a module is not enabled as the result of this procedure, its
118
+ // Startup function is not invoked. This allows a single executable
119
+ // with various optiona capabilities to be built, and a subset of those
120
+ // capabilities to be enabled by the OptionalModules parameter. The
121
+ // executable's capabilities can later be modified by editing that
122
+ // parameter in the configuration file and performing a reboot restart.
100
123
//
101
124
virtual void Enable ();
102
125
0 commit comments