Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020304180044.00b88ca0@localhost>
Date: Mon, 04 Mar 2002 18:04:05 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: apr_file_open() and caching file descriptors
In-Reply-To: <Pine.LNX.4.44.0203041826010.1666-100000@deepthought.cs.vir
 ginia.edu>
References: <010901c1c3d1$b8841690$06000100@sashimi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:29 PM 3/4/2002, you wrote:
>On Mon, 4 Mar 2002, Bill Stoddard wrote:
>
> > Rather than an option to not register a cleanup, perhaps a function to
> > kill the cleanup would be more generally useful.
> >
> > apr_file_kill_cleanups(apr_file_t *file);
>
>You still have a problem with the apr_file_t disappearing when r->pool
>goes away, meaning you'd still need the apr_os_file_get/put thing, which
>just doesn't seem like a good idea to me.  There has got to be a good way
>to do this... I'll keep thinking on it and get back to you asap.

Caching introduces tons o' headaches.

You won't like it, but you need a cross process cache pool derived from
process->pool.  Individual cache entries should each gain a subpool of
their own ... if you do it right, the 'remove from cache' function is a cleanup
of that subpool.  So you create a cache subpool for an entry, initialize it,
put it in the cache list, and when they go to destroy that 'entry' (the pool
itself) the file and memory is cleaned up, and the entry removed from the
cache list.

That's the most elegant design I can picture.  Performance wise??? well...
I don't have a good idea of how that would perform.

The only obvious alternative is to 'reuse' apr_file_t's with apr_file_os_put
or apr_file_dup or something like that.  It's a legit option worth considering.

Bill