On 10/29/2008 08:40 PM, Paul Querna wrote: > Jorge Schrauwen wrote: >> I think for a large configurations, the copy on write is a >> significant optimisation - you can have large numbers of processes, >> and a large configuration, and get away with it, as practically the >> configuration is only memory resident once. >> >> I think it would be important to still support both, but certainly >> the code to support both shouldn't be at all complex. Perhaps the >> choice of which to choose could be configurable, so that Leopard >> users could choose "config via pipe". >> >> >> If you are going to implement both methodes... >> fork() should be used and exec and pipe the config as a fallback. > > > Well, part of the problem is that many current apache modules assume > that the parent and child are fork'ed from one another -- this is a > wrong assumption of course, since,it doesn't work on win32 that way -- > but most of those modules are win32 only of course. If we do this on > unix, we will break all of those modules. > > Of course, maybe that is a good thing, since then they would be ported > forward and work on win32 too.
I guess this would be a huge problem for making simple MPM the default MPM in 2.4 as this might require significant changes to the modules that go far beyond recompiling. So I would say that we should implement both and have it configurable (ideally at config time). Why? This allows to make performance tests and compare the difference between fork and non fork in different configurations. If it turns out that keeping both implementations is a PITA and that there is no notable gain in using fork we can drop fork off in the next major release after 2.4. This also gives the module authors more time to adjust themselves to a non fork MPM even if they don't work under Windows. Regards Rüdiger
