At 03:25 AM 3/18/2003, Joe Orton wrote: >> >Hi, here is a version of the patch in #17206 which removes the current >> >the fd leaks. Most of these were introduced in this commit >> > >> >http://marc.theaimsgroup.com/?l=apache-cvs&m=99531770520998&w=2 >> > >> >though the pod leak has been around longer. I haven't checked whether >> >the mod_file_cache change in that commit should be reverted as well. The >> >patch is against 2.0 HEAD. >> > >> >Submitted by: Christian Kratzer, Bjoern A. Zeeb >> >> +1 here. I have one comment; please *don't* simply delete those lines >> from server/log.c, modules/mappers/mod_rewrite.c and, of course, >> modules/loggers/mod_log_config.c. Please comment them out with >> /* XXX: this would be required in the Win32 parent */ > >I don't really understand this... the file_inherit interface concerns >whether files are inherited by exec()d processes, not any "child >processes", on Unix. Is there some mismatch in the Win32 >implementation? Why should httpd need this APR call specifically for >Win32?
As I mentioned before, I'm +1 on this patch. I'll put back the appropriate comments in httpd-2.1-dev since this will be nearly impossible to fix for Win32 without breaking many things that we wouldn't consider good for the health of 2.0-releases. Our mutual confusion (which I explained over on apr) is that httpd fork()s it's worker processes. In that sense, they are only sort-of child processes. They aren't subject to FD_CLOEXEC and don't respect the "child" pool cleanups. On Win32, we exec() (actually, we CreateProcess()) our worker processes. That means our workers are truly "child" processes. So to do things 'right', we need to inherit common handles from the parent process, tell the child worker process about them, and the child worker process must then make them uninheritable once again on Windows. We need something slick and abstract enough for Unix and Win32 so that the right inheritence is used by platform, the handles survive from the parent to the worker, and httpd mpms take care of all the dirty details. I'm working on designs now and should have something to propose to 2.1-dev over the next month. It won't be proposed for back porting to 2.0, but it should make it into 2.1-dev quickly enough to give 2.2 module maintainers that are affected enough time to react to the API, provide feedback and fix their modules. Bill
