On 16/10/09 11:21, Joe Orton wrote:
On Fri, Oct 16, 2009 at 11:17:17AM +0200, Mladen Turk wrote:
each invocation to apr_file_open_stdout creates a new apr_file_t so
each fd->filedes has a value of STDOUT_FILENO.
This is the same as calling:
close(1);
close(1);
Oh, good point. This is rather horrible :(. I'm not sure what can be
done about it, we can't change apr_file_open_stdout() to do a dup()
internally, since that would break existing apps.
I'm not sure why do we call close(0..2) for std files when
the apr_file_open_std* is closed or it's pool destroyed at the
first place.
Reading the:
* @remark The only reason that the apr_file_open_std* functions exist
* is that you may not always have a stderr/out/in on Windows. This
* is generally a problem with newer versions of Windows and services.
So apr_file_open_std* should just reference the existing
system descriptors. However it behaves like 'attach' rather then open,
meaning once you open it you will destroy the system stdin/stdout/stderr.
Thus by design it's a singleton operation, so if desired,
the second invocation during the process lifetime should always
return EBADF for apr_file_open_std* thought.
Very confusing.
Regards
--
^TM
