This section contains a synopsis of the modules being shipped and which use knowledge of the MAL runtime context. They are sorted by module name and repetitive reading may be required to understand all details.
Module Loading
The server is bootstrapped by processing a MAL script with module definitions or extensions. For each module file encountered, the object library lib_<modulename>.so is searched for in the location identified by monet_mod_path=exec_prefix/lib/MonetDB5:exec_prefix/lib/MonetDB5/lib:exec_prefix/lib/MonetDB5/bin.
The corresponding signature are defined in .../lib(64)/<modulename>.mal.
The default bootstrap script is called .../lib/MonetDB5/mal_init.mal and it is designated in the configuration file as the mal_init property. The rationale for this set-up is that database administrators can extend/overload the bootstrap procedure without affecting the software package being distributed. It merely requires a different direction for the mal_init property. The scheme also isolates the functionality embedded in modules from inadvertise use on non-compliant databases.
Unlike previous versions of MonetDB, modules can not be unloaded. Dynamic libraries are always global and, therefore, it is best to load them as part of the server initialization phase.
Module file loading
The default location to search for the module is in monet_mod_path unless an absolute path is given. Loading further relies on the Linux policy to search for the module location in the following order: 1) the colon-separated list of directories in the user's LD_LIBRARY_PATH, 2) the libraries specified in /etc/ld.so.cache and 3) /usr/lib followed by /lib. If the module contains a routine _init, then that code is executed before the loader returns. Likewise the routine _fini is called just before the module is unloaded.
A module loading conflict emerges if a function is redefined. A duplicate load is simply ignored by keeping track of modules already loaded.
- Printer-friendly version
- Login to post comments