 |
MySQL 9.1.0
Source Code Documentation
|
|
MySQL 9.1.0
Source Code Documentation
|
The dynamic loader Service is one of the core Services of the MySQL Component subsystem. It is responsible for loading new components, register the services they implement, resolve dependencies and provide service implementations for these dependencies to the component. It is also responsible for unloading components, effectively reversing the effect of load operation in mostly reverse order, in unload method().
Macros to help define components are listed in component_implementation.h.
To use the provided services a reference to the required service implementation must be obtained from the registry: either explicitly via calling the registry service methods or implicitly by declaring it into the component's metadata so that the dynamic loader can satisfy that dependency at component load time. Once the service reference is no longer needed the reference to it must be released. The registry keeps reference counts for each service implementation it lists to track if a service implementation is used or not.
Components are not reference counted, as they do not communicate with other components in any other way but via service references. And since service implementations are reference counted the dynamic loader can reliably detect if all service implementations a component provides are unused and can safely unload the component.
Component names are structured in such a way that allows components from multiple sources to be loaded. Each component is specified by a URN of "scheme://path", where "scheme" defines which dynamic loader scheme service to use to acquire the component definition. Single URNs can contain several components.
A basic dynamic loader scheme service is implemented for the "file://" scheme (see dynamic_loader_scheme_file.cc), which accepts a path to a dynamic library to load components from using the OS dynamic library APIs. This dynamic loader scheme implementation does not rely on any server functionality and hence can be placed into the component infrastructure core (a.k.a. the minimal chassis).
An additional service implementation, the path filter dynamic Loader "file://" scheme service implementation, is provided for the "file://" scheme as wrapper on any already registered file scheme dynamic loader service implementation, that assumes a path argument is just a filename without extension and limits shared libraries to be loadable only from the MySQL server plug-in directory. The filter is implemented as a separate service implementation as it requires access to the server internal variables (the plugin directory path) and is hence implemented into the server component. This also demonstrates how other components can reimplement functionality provided by a component via setting a new default implementation of a service they want to re-implement.
The dynamic loader scheme service for "builtin://" was designed to include components that were meant to be statically linked into MySQL executable, but to comply with the components requirements, that is mainly to assure components do not interact with any other component in ways not meant by the components subsystem, i.e. not through the services in the service registry. This is easily asserted by housing components in separate dynamic libraries. This makes the "builtin://" scheme, a bit of a bad practice as it breaks the safeguard of having only one component in a OS binary. Thus currently the scheme name is reserved but no implementation of it is provided.
1.9.2