![]() |
MySQL 8.3.0
Source Code Documentation
|
The core of the component infrastructure is the so called "minimal chassis". It consists of implementations of the registry and the dynamic loader. These are enough to bootstrap the subsystem and do not require any extra functionality.
The minimal chassis can theoretically be embedded into any binary (be it an executable or a shared library) and can be used to provide extensibility to it. Hence it can even be isolated into a standalone library.
However the minimal chassis is currently is statically linked into the server executable. Since the minimal chassis is logically independent it can (and is) initialized very early in the server bootstrap process.
The minimal chassis lacks an impelmentation of persistent storage, i.e. every time it's bootstraped it will only contain the registry and the dynamic loader services. While this is a good basis it lacks a central functionality expected from a mysql server extension system: keep a persisted list of extensions that are to be loaded automatically into the infrastructure in an orderly way to provide the functionality contained in them to server users.
Hence an extra logical layer is added on top of the minimal chassis:
The minimal chassis library has three exposed apis those are:
Note: minimal chassis support the native implementation of rwlocks and trylocks and it doesn't support the prlock because the prlock native implementation depends on mysql server code.
The server component is currently the whole of the server binary code. It's not loaded dynamically (as any ordinary component is) since it's embedded into the same OS binary as the minimal chassis: the mysql server executable binary. As any other component the server component too can expose any of the functionality it encapsulates via the service implementations it provides to the other components in the component infrastructure.
The server component is initialized relatively late in the bootstrap process: when all of the server is initialized and it's ready to "go" (i.e. accept client connections). At that time the component persistency table is read and all of the component sets defined in it are loaded and initialized.
Note that, albeit being in the same binary (component) the server component and the minimal chassis are and should remain two distinct layers. Mostly to allow safe reuse of the minimal chassis in other binaries.
The elements of the minimal chassis are implemented in components/libminchassis and the implementations of services the server component provides are to be found in sql/server_component/