Re: svn commit: r581063 - in /apr/apr/branches/1.2.x: CHANGES file_io/win32/filedup.c file_io/win32/open.c include/apr_thread_proc.h include/arch/win32/apr_arch_file_io.h threadproc/win32/proc.c

[Joe Orton <jo...@redhat.com>]

On Mon, Oct 01, 2007 at 08:22:04PM -0000, William Rowe wrote:
> Author: wrowe
> Date: Mon Oct  1 13:22:04 2007
> New Revision: 581063
> 
> URL: http://svn.apache.org/viewvc?rev=581063&view=rev
> Log:
> Introduce APR_NO_FILE as an option to apr_procattr_io_set() for any 
> of the three stdio streams to cause the corresponding streams to NOT
> be inherited to a WIN32 child process (passes INVALID_HANDLE_VALUE).
> 
> This is of little importance to most developers, except those who had
> exploited an inconsistency between Unix and Win32 that was corrected
> on Win32 with APR version 1.2.10.
> 
> The feature to have NO_FILE work across platforms and leave a specified
> std stream closed becomes portable in APR version 1.3.0 (it remains 
> equivilant to APR_NO_PIPE on non-Windows platforms throughout version 
> APR 1.2.x).

This is an API extension so can't be backported to the 1.2.x branch (per 
the versioning rules).

joe

Re: svn commit: r581063 - in /apr/apr/branches/1.2.x: CHANGES file_io/win32/filedup.c file_io/win32/open.c include/apr_thread_proc.h include/arch/win32/apr_arch_file_io.h threadproc/win32/proc.c

[Joe Orton <jo...@redhat.com>]

On Tue, Oct 02, 2007 at 01:54:03PM -0500, William Rowe wrote:
> Joe Orton wrote:
> > 
> > This is an API extension so can't be backported to the 1.2.x branch (per 
> > the versioning rules).
> 
> Which explains why you responded to the original post how?
> 
> In a rare turn, this doesn't actually introduce any API.  I was very explicit
> in pointing this out, and asking a week ago for the feedback of the developers.

I'm not sure how adding a new macro to a public header and adding a new 
interface guarantee if that macro is used can be considered as anything 
other than "introducing a new API".

If the procattr API is so ill-defined that it can't be implemented 
portably and it requires interface extensions to fix that, so be it (no 
argument here), but the versioning rules require that such changes have 
to wait for 1.3.0.

joe

Re: svn commit: r581063 - in /apr/apr/branches/1.2.x: CHANGES file_io/win32/filedup.c file_io/win32/open.c include/apr_thread_proc.h include/arch/win32/apr_arch_file_io.h threadproc/win32/proc.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Orton wrote:
> 
> This is an API extension so can't be backported to the 1.2.x branch (per 
> the versioning rules).

Which explains why you responded to the original post how?

In a rare turn, this doesn't actually introduce any API.  I was very explicit
in pointing this out, and asking a week ago for the feedback of the developers.

Let's be clear;

1.2.8 was not portable behavior; violated APR, but was the API for Win32.

1.2.11 restored portability to the Unix model; broke a few, far between
applications of APR on Win32.

1.2.12 proposes to retain the restored portability in all but the most
unusual edge cases who presumed our API for Win32 was correct.

I'd be happy to keep this, remove the APR_NO_FILE flag, hint to that
application developer of the hardcoded constant, and let them roll their
dice for expecting APR to provide grok that constant.  With APR 1.3/httpd 2.4
they would be able to get rid of the const value cruft.

If you want to scroll back and respond to the final analysis thread named;

"Solution to apr stdio/msvc crt/service handles and logging"

... I took the time to thoroughly dissect the issue, if you want to weight
in, that would be the thread to do it on.

We have two purposes to serve on the 1.2.x branch; let people expect portable
behaviors, and attempt to avoid breaking people who weren't looking at the
portability of behaviors.

This is the only compromise I could arrive at.  It doesn't require changes
to functions, or arg types, or return types.  It's strictly the introduction
of a MACRO which will not 'harm' any existing app.

If you want to veto the patch; propose an alternative that serves both the
purpose of portability and the purpose of those who relied on the older non
portable behavior.

Bill