So I've been taking a look at the new work Paul's been doing on the fcgi-proxy-dev branch, and it looks really cool, but I've got some questions on its direction. What's there now is the beginnings of functionality to let you use mod_proxy to send requests for particular parts of the URL space to a back end FastCGI process. This is fantastic, but it's only part of the equation. We also need some mechanism for actually starting and managing the FastCGi processes.
One of the things people like about lighttpd is the way it can start up N back end processes, then if one of them dies for some reason it'll simply restart it for you. In order to do this kind of thing it seems like we'll need something keeping track of what FastCGI processes have been started, which are currently in use, and other such bookkeeping information. Now since we need to be able to run in multiprocess configurations, that means either the bookkeeping data needs to be kept in shared memory, or all this info needs to be managed by a separate child process (similar to the mod_cgid stuff I imagine). The separate child process plan seems easier to implement correctly, but it also means that the process of grabbing hold of a FastCGI process would reqiure some sort of IPC, sending requests over a socket or something, which is potentially slow. I suppose this could be made less of an issue by introducing some sort of scheme where a httpd process can hold on to a back end FastCGI process as long as it wants to use it, which is fine as long as the manager child can tell when the httpd process has died or otherwise gone to never never land so it can either regain control of the FastCGI process or kill it and start another. Personally, I'm leaning towards the manager child process way of doing things just for ease of implementation, since we can always go with something else later if it proves necessary. Anyway, just some ideas that had been kicking around in the back of my mind. Has anyone else put any work this part of the FastCGI stuff? -garrett
