Re: moving towards loadable MPMs

Paul Querna wrote: I was hoping someone will address the separation of child process management from the mpm. Majority of this stuff is common and duplicated across mpms while there can be an api for that thought. Yes, the simple mpm inteded to go there, and only uses APR functions for threadp

Re: moving towards loadable MPMs

On Tue, Mar 24, 2009 at 2:42 PM, Mladen Turk wrote: > Jeff Trawick wrote: >> >> On Tue, Mar 24, 2009 at 12:41 PM, Mladen Turk > > wrote: >> >>    Jeff Trawick wrote: >> >> >>        (no plans here to touch WinNT MPMs, and I don't see any >>        compelling reason to leav

Re: moving towards loadable MPMs

Jeff Trawick wrote: On Tue, Mar 24, 2009 at 12:41 PM, Mladen Turk > wrote: Jeff Trawick wrote: (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

Re: moving towards loadable MPMs

On Tue, Mar 24, 2009 at 12:41 PM, Mladen Turk wrote: > Jeff Trawick wrote: > >> >> (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) >> >> > The major problem with that is th

Re: moving towards loadable MPMs

Jeff Trawick wrote: (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) The major problem with that is the huge amount of platform dependent code for managing the service, reg

moving towards loadable MPMs

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 remov