Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <027801c1b35f$d5b2e2a0$94c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>,
	<httpd-2.0-cvs@apache.org>
References: <20020212001134.64582.qmail@icarus.apache.org>
Subject: Re: cvs commit: httpd-2.0/server log.c
Date: Mon, 11 Feb 2002 18:54:30 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

> wrowe       02/02/11 16:11:34
> 
>   Modified:    server   log.c
>   Log:
>     This code seriously misassumed (and may yet) that stderr was a valid file.
>     It also has some bogus non-apr code that probably does great evil to win32
>     services.  This must be bumped into .32, code review is incomplete still.
>   
>   Revision  Changes    Path
>   1.107     +5 -3      httpd-2.0/server/log.c
>   
>   @@ -306,6 +307,7 @@
>        /* note that stderr may still need to be replaced with something
>         * because it points to the old error log, or back to the tty
>         * of the submitter.
>   +     * XXX: This is BS - /dev/null is non-portable
>         */
>        if (replace_stderr && freopen("/dev/null", "w", stderr) == NULL) {
>            ap_log_error(APLOG_MARK, APLOG_CRIT, errno, s_main,

This freopen is so friggin bogus - I'm absolutely -1 on this specific code 
being included in _any_ subsequent 2.0 [alpha, beta, whatever] release!  

While the Bills and Ryan have been at each other's throats over who broke
the WinNT MPM - it wasn't anyone... every rearrangment of the service code
relocated _which_ handle was spuriously closed by borked logging or other
code.

If this is true - we are closing things we had already closed - this could
indiciate some very serious misbehavior applicable to all MPMs.  Win32 reuses
handles frequently - but all handles come from the same 'pool' - so the 'events'
we saw closed underneath our feet could have been closed by locking, files, dsos
or any other code that closes any sort of handle.

Therefore I'd suggest we hold until I or someone else tracks down the offensive/
offending code, be it in logging or elsewhere.  Once that's done we might have 
a candidate suitable for beta (and close to GA quality :)

And Bill - drop the attitude - the fact that Win32 never checked the child proc
exit code before last week, as every unix mpm (and 1.3 unix code) has done forever 
demonstrated some really slipshod workmanship.  Pulling together and progressing 
the code forward instead of sniping at one another is much more productive.
None of us are perfect.

Bill