Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 26 Jun 2001 08:41:57 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: Cliff Woolley <cliffwoolley@yahoo.com>
Cc: dev@apr.apache.org
Subject: Re: file_setaside()
Message-ID: <20010626084157.J25512@ebuilt.com>
References: <20010626082254.I25512@ebuilt.com>
 <Pine.GSO.4.32.0106261123590.18662-100000@cobra.cs.Virginia.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.32.0106261123590.18662-100000@cobra.cs.Virginia.EDU>;
 from cliffwoolley@yahoo.com on Tue, Jun 26, 2001 at 11:29:32AM -0400

On Tue, Jun 26, 2001 at 11:29:32AM -0400, Cliff Woolley wrote:
> On Tue, 26 Jun 2001, Justin Erenkrantz wrote:
> 
> > Why?  Don't we need to create a duplicate file handle?  What am I
> > missing?  -- justin
> 
> Not for file_setaside() we don't.  All file_setaside() cares about is that
> the apr_file_t and its associated locks and stuff get put into the
> appropriate pool.  The apr_os_file_t file handle that is referred to by
> the apr_file_t knows nothing about pools (it's just an int or HANDLE or
> HFILE or whatever).  So we can keep the same apr_os_file_t and just wrap a
> new apr_file_t around it.  No call to the OS's dup() is needed.  Make
> sense?

What about the case where the original apr_file_t is cleaned up 
(i.e. closed) before we are done with the "new" apr_file_t?  (This is
the whole purpose of setaside, right?)  Won't that cause a problem 
since the original descriptor has now been closed in kernel space?  
We'll have ourselves a nice invalid file descriptor.  Or, am I
wrong?  -- justin