As discussed in the overview, modules are logical groupings of code which together implement some subset of the NASD API, or provide some set of functionality. Some modules have many entrypoints, some have only a few.
In addition to whatever operations they are designed to provide, all modules
provide entrypoints for initialization and shutdown. Before any entrypoints
provided by the module may be accessed, the initialization entrypoint must
be called. If this is not done, many modules will return NASD_SYS_NOT_INITIALIZED
from some or all entrypoints. Although it is recommended that all modules
do so, it is not mandatory. When a module is no longer needed, its shutdown
entrypoint should be called. It is expected that these entrypoints will be called
rarely. For example, a long-running application might initialize the module
once upon startup, and shut it down once at exit time.
Because modules may rely upon one another, and many interrelated modules may
be compiled into a single address space, the initialization state of a module
is reference counted. That is, if a module is initialized N
times,
and shut down N-1
times, it will still be active until it is shut
down one more time. Users of modules may take advantage of this to simplify
their own initialization and shutdown, as well as interactions with other
modules and subsystems.
To avoid core leaks, it is important for modules which use other modules to shut down the modules they are using when they are in turn shut down. That is, if module A initializes module B, when module A is shut down, it must in turn shut down module B.
Adding modules is documented in a separate section.
![]() | ![]() | ![]() |
---|---|---|
Results and errors | Threads | NASD Programmer's Documentation |