> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: 10 April 2002 20:41
> On Wed, Apr 10, 2002 at 10:17:38AM -0700, Ryan Bloom wrote: > > > > http://www.geocrawler.com/archives/3/417/2000/2/200/3308893/ > > > > This has been the historic reason for not doing it. > > Since APR is handling the abstraction of threads and it is always > providing the ability to call the OS's threads (only not when > --disable-threads or the OS doesn't support it), I just don't see > Dean's reasoning as being valid given our current code base. We'd > always be thread-safe/thread-aware even if our MPM doesn't support > it as long as APR does support threads. > > If an MPM were not to use APR's thread abstractions, then perhaps I > see his point. And, I believe that was his initial rationale for > MPMs - ability to do platform dependent code (in spite of APR). But, > given our MPMs, it seems that this doesn't need to be the case. > > Obviously, for Win32, BeOS, and Netware, this isn't a win. But, for > Unix it might be. And, binbuilds especially. -- justin What would be even more cool would be to be able to load multiple mpms at the same time... And to configure which mpm handles a certain socket (or other I/O resource). I can imagine mod_pop3, for example, having different mpm requirements as mod_http (and all the http related modules). Ofcourse this is probably better left for 2.1/3.0. Sander
