At 01:09 PM 3/21/2003, Jeff Trawick wrote:
I'm a bit nervous about the existing/new special handling for descriptors 0-2.
Are you looking at my original or new patch?
either
I won't disagree, if you want apr_file_dup() to always return an uninherited handle, that isn't a problem. Just look in the which_dup == 1 logic of my patch and change that block to always untoggle APR_INHERIT (and we should also untoggle APR_FILE_NOCLOSE for apr_file_dup() results, now that I think about it.)
Why isn't the problem this:
Apache opened stderr from the wrong pool, or failed to open it again when the original pool for stderr was cleaned up; in other words, it was cleaned up because of a pool lifetime problem in the application, not because 0-2 inherently need to be handled in a different special way
Because we agreed that the API would support APR_FILE_NOCLOSE and that is how apr_file_stderr_open() works.
you mean APR_FILE_NOCLEANUP? I'll buy that, except that I can't see the connection between apr_file_open_stderr() and APR_FILE_NOCLEANUP
APR_DECLARE(apr_status_t) apr_file_open_stderr(apr_file_t **thefile,
apr_pool_t *pool)
{
int fd = STDERR_FILENO;return apr_os_file_put(thefile, &fd, 0, pool); }
(and maybe in addition: Apache should be able to tell apr_proc_detach() to leave stderr alone if it wants fd 2 to be unchanged across the detach)
Hmmm. Interesting point, but I think that if we just respect the values for APR_FILE_NOCLOSE and APR_INHERIT - as my most recent patch suggests, that this problem should simply go away.
I suspect that it will "simply go away" in that it will "not be noticably broken" since we will get fd 2 pointing to the error log again instead of /dev/null before too many opportunities for writing to stderr go by.
