MPMs are tightly bound into the server through several mechanisms: they define key functions ap_mpm_query and ap_mpm_run they define global variables like ap_server_conf build-time symbols in MPMDIR/mpm.h that enable generation of support code or provide macros for core to use
I'm working on removing these ties. * key functions are replaced with hooks * global variables are moved to http_main if necessary or replaced with ap_mpm_query() calls if possible * core will provide as much MPM support code as practical (resulting in a small amount of extra code for users that don't switch MPMs) stage 1: reduce the ties but don't change the build process (i.e., leave MPMs as compiled-in module) at this stage, WinNT MPM will still provide mpm.h but will indicate which support code NOT to supply * only winnt MPM will retain mpm.h, and it will have a bunch of AP_MPM_NO_foo instead of a small number of AP_MPM_WANT_foo; punt on mpm_common having a better picture of which functions to generate) (no plans here to touch WinNT MPMs, and I don't see any compelling reason to leave it broken; it should build as before once the inevitable minor slips are corrected) stage 2: allow building as shared object one issue is whether to support the expected --with-mpm=FOO as the way to select an MPM in the traditional, built-in style we could have --with-mpm=FOO still provides built-in MPM; no --with-mpm=FOO but --enable-worker=shared --enable-prefork=shared builds the DSOs for switching or just use normal module enablement but check for multiple statically-enabled MPMs (FWIW, MPM hooks run first and declared APR_HOOK_MIDDLE so only one of multiple loaded MPMs would be used) Any concerns with the general idea, or comments with either stage? Any concerns with committing to trunk once stage 1 has been completed for a few MPMs (and I think there's a reasonable chance of Windows MPM still working)?
