Thanks to the feedback from Joe and Bjoern, I have committed a ton and 1/2 of bug fixes to apr's open.c and dupfile.c.
After those changes, this patch is much easier to read. Please take a look and comment on anything you see that might be amiss. If there are ANY remaining bugs in the current implementation of APR_INHERIT (ignoring the non-apr fork()/exec() issues that this patch addresses now) they should be fixed immediately. I reserve my extreme opinions for Win32 matters, I won't express any opinion on wether or not this patch should be in 0.9.2. I offer it for completeness. Provided the developer is using apr_proc_create, today they should end up with no unintended handles in Unix child processes from our apr_file_t or apr_socket_t entities. If this is not true, scream loudly. I'm actually concerned about inheritance of the various semaphores, mutexes, locks and shm's. I'm sure I can count on Bjoern to let us know if we still have work to do in those 'other departments'. Oh, this patch has one flaw, and I'm hoping someone suggests an easy solve. I do bother testing the APR_FILES_AS_SOCKETS to avoid trying to toggle a value which would be quite invalid. However, that's only partially effective since we use the same implement logic. Perhaps we should we always provide both APR_IMPLEMENT_INHERIT_UNSET and an alternate APR_IMPLEMENT_INHERIT_UNSET_CLOEXEC, and leave the decision to use the _CLOEXEC flavor to open.c and sockets.c to decide? Bill
