Akins, Brian wrote: >> This gives us the option of prefork reliability, and event driven speed, >> as required by the admin. > > I think if we try to do both, we will wind up with the worst of both worlds. > (Or is it worse??) Blocking/buggy "modules" should be ran out of process > (FactCGI/HTTP/Thrift).
That is exactly what prefork means - to run something out of process, so that it can leak and crash at will. I disagree we'll end up with the worst of both worlds. A lot of head banging in the cache code has been caused because we are doing blocking reads and blocking writes on the filter stacks. When I say "be asynchronous" I mean use non-blocking reads and writes everywhere, in both prefork, worker and event. We know from 15+ years of experience that prefork works, and we know from the same period of experience from others that a pure event driven model is useful for shipping static data and not much further. But some people have a need to just ship static data, and there is no reason why httpd and an event MPM can't do that job well too. Regards, Graham --
