From rbb@covalent.net Mon Feb 5 23:02:28 2001 Return-Path: Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Delivered-To: mailing list dev@apr.apache.org Received: (qmail 26699 invoked from network); 5 Feb 2001 23:02:28 -0000 Received: from sfo-gw.covalent.net (HELO koj.covalent.net) (207.44.198.62) by h31.sny.collab.net with SMTP; 5 Feb 2001 23:02:28 -0000 Received: from rbb (helo=localhost) by koj.covalent.net with local-esmtp (Exim 3.16 #1) id 14PuhY-0004X0-00; Mon, 05 Feb 2001 15:05:40 -0800 Date: Mon, 5 Feb 2001 15:05:40 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: Greg Stein cc: dev@apr.apache.org Subject: Re: cvs commit: apr STATUS In-Reply-To: <20010204143425.W26044@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > > + * 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 -------------------------------------------------------------------------------