An Introduction to Apache 2.0 Page 2
This abstraction had an unexpected benefit as well: it allows Apache to be configured for a specific site depending on the Webmaster's requirements. When the work began on UNIX, MPMs the developers couldn't agree on the correct design. Three MPMs have been developed so far prefork, mpmt_pthread, and dexter. The prefork MPM does exactly what Apache 1.3 does it acts as a pre-forking server. Mpmt_pthread stands for multi-threaded multi-process pthread server. When this MPM was first written, it required that pthreads was used as the threading library. However, it is now taking advantage of the Apache Portable Run-Time to abstract out the threading library. The name has unfortunately remained. This is the initial version of a hybrid thread/process server for UNIX. This MPM also preforks a specified number of processes. Each of these processes then creates a specified number of threads which serve the requests. In this MPM, the number of threads per process is static. Finally, the dexter MPM was created. This MPM creates a specified number of child processes, which then each create a small pool of threads. As more requests come in, the size of that pool of threads grows and shrinks to accommodate the requests.
Modifications to Modules
Since this article started with a new type of module, the obvious next topic is a module that Apache users everywhere are familiar with, the standard Apache module. These are the modules that people use to add capabilities such as authorization checking to a server. There have been a few modifications made to standard modules which module writers need to be aware of.
One of the most frequent complaints by new module authors about Apache 1.3 is that the initializer hook is called twice. This issue has been resolved in Apache 2.0, as the initializer hook has been removed completely. Instead of using one hook, Apache 2.0 has provided two hooks: pre_config and post_config. In the third alpha of 2.0, only MPMs could take advantage of pre_config hooks. That issue is currently being resolved and all modules should have access to the pre_config hook with the release of Apache 2.0 alpha 4.
The configuration method for Apache has also changed with Apache 2.0. This affects how some directives are defined and how some modules must use the new pre_config hook.
The biggest change between 1.3 and 2.0 when it comes to configuration is that in 1.3, Apache configures the server one line at a time as it is read from the configuration file. In Apache 2.0, each line is read from the configuration file and is stored in a configuration tree. The tree is then traversed and each directive is executed.
If the module you are writing has a directive that modifies how the server interprets the configuration it should be declared with the EXEC_ON_READ flag on in the req_override mask. This tells Apache 2.0 to execute the appropriate function when this directive is read instead of when walking the tree. Very few functions should use this flag, but if the directive needs to read in raw text from the configuration file or process a whole block of configuration text, this flag provides a way to do that.
Once the configuration is read into the tree structure, the pre_config hook is called. This provides a way for modules to modify the tree before it is traversed. Once all of the modules have run their pre-config hooks, the core walks the tree and finishes configuring the server.