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
