You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by gs...@apache.org on 2001/02/04 22:37:49 UTC
cvs commit: apr STATUS
gstein 01/02/04 13:37:49
Modified: . STATUS
Log:
sun. lots. good.
Revision Changes Path
1.34 +5 -1 apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr/STATUS,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -u -r1.33 -r1.34
--- STATUS 2001/01/29 06:21:36 1.33
+++ STATUS 2001/02/04 21:37:49 1.34
@@ -1,5 +1,5 @@
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
-Last modified at [$Date: 2001/01/29 06:21:36 $]
+Last modified at [$Date: 2001/02/04 21:37:49 $]
Release:
@@ -111,6 +111,10 @@
* add the rest of the pool accessor declare/impl macros.
Status: Greg volunteers
+
+ * I think apr_open_stderr() and friends dup() the descriptor. That
+ would allow the new/returned file to be closed (via pool cleanup
+ or manually) without accidentally closing stderr/out.
Documentation that needs writing:
Re: cvs commit: apr STATUS
Posted by rb...@covalent.net.
> > > + * I think apr_open_stderr() and friends dup() the descriptor. That
> > > + would allow the new/returned file to be closed (via pool cleanup
> > > + or manually) without accidentally closing stderr/out.
> >
> > The goal of those functions is to actually get stderr, stdout, stdin into
> > an apr_file_t. The only reason they exist, is because Windows requires an
> > extra function to get stderr, stdout, stdin when we use native file
> > types. If you want to dup them, then that should be done by you
> > explicitly. There is no reason to cause that extra call for programs that
> > know they don't want to do the dup.
>
> Subversion makes ample use of subpools. If the apr_file_t for stderr was
> placed into a subpool, then the thing would get closed when a pool cleanup
> occurred.
>
> And I can't dup the file after it has been placed into an apr_file_t. The
> first will continue to exist, and would get closed on cleanup.
I guess I am confused why you can't use apr_open_std*() and then call
apr_file_dup() on the file_t. If you then call apr_close_file on the file
returned from apr_open_std*, you should be fine, because you will have two
references to the file, and closing one shouldn't hurt anything.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr STATUS
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 04, 2001 at 01:54:52PM -0800, rbb@covalent.net wrote:
>
> > + * I think apr_open_stderr() and friends dup() the descriptor. That
> > + would allow the new/returned file to be closed (via pool cleanup
> > + or manually) without accidentally closing stderr/out.
>
> The goal of those functions is to actually get stderr, stdout, stdin into
> an apr_file_t. The only reason they exist, is because Windows requires an
> extra function to get stderr, stdout, stdin when we use native file
> types. If you want to dup them, then that should be done by you
> explicitly. There is no reason to cause that extra call for programs that
> know they don't want to do the dup.
Subversion makes ample use of subpools. If the apr_file_t for stderr was
placed into a subpool, then the thing would get closed when a pool cleanup
occurred.
And I can't dup the file after it has been placed into an apr_file_t. The
first will continue to exist, and would get closed on cleanup.
Creating an apr_file_t for stderr/out/in is fine, but that cleanup is a
problem, and the dup is the only solution that I've figured out so far.
Other ideas are welcome; it certainly won't be "soon" that I get into that
code to do the dup... we have time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr STATUS
Posted by rb...@covalent.net.
> + * I think apr_open_stderr() and friends dup() the descriptor. That
> + would allow the new/returned file to be closed (via pool cleanup
> + or manually) without accidentally closing stderr/out.
The goal of those functions is to actually get stderr, stdout, stdin into
an apr_file_t. The only reason they exist, is because Windows requires an
extra function to get stderr, stdout, stdin when we use native file
types. If you want to dup them, then that should be done by you
explicitly. There is no reason to cause that extra call for programs that
know they don't want to do the dup.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr STATUS
Posted by rb...@covalent.net.
> + * I think apr_open_stderr() and friends dup() the descriptor. That
> + would allow the new/returned file to be closed (via pool cleanup
> + or manually) without accidentally closing stderr/out.
The goal of those functions is to actually get stderr, stdout, stdin into
an apr_file_t. The only reason they exist, is because Windows requires an
extra function to get stderr, stdout, stdin when we use native file
types. If you want to dup them, then that should be done by you
explicitly. There is no reason to cause that extra call for programs that
know they don't want to do the dup.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------