apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lucian Adrian Grijincu <lucian.griji...@avira.com>
Subject Re: apr_dir_remove_recursively status
Date Fri, 15 Dec 2006 11:29:40 GMT
You're right, that was quite a memory hog.
I've rewritten it and this looks quite OK to me.

    * make 2 pools: one to hold the stack directories and one for temp data
    * create the stack and push the passed-in directory parameter
    * while (!is_stack_empty)
          o clear the temp pool
          o find the full path to the current directory (concat all the
            entries in the stack)
          o loop through the files in the current dir
                + if a file is a directory, push it to the stack and
                  break out of the inner loop
                + delete all the rest of the files
          o if we didn't break out of the loop, we must have deleted
            everything inside the directory, so delete this directory
            and pop it from the stack
    * cleanup pools

Joe Orton wrote:
> On Thu, Dec 14, 2006 at 03:57:18PM +0200, Lucian Adrian Grijincu wrote:
>> I've modified the version posted earlier(2001) by Ben Collins-Sussman in
>> this way:
> Hi Lucian, thanks for sending the patch in.
> The way that's written has pretty bad memory consumption behaviour.  
> Using stack recursion to iterate down the directory tree is not really 
> going to fly; it is liable to cause a stack overflow and crash for a 
> really deep directory tree.  Eating pool memory proportional to breadth 
> *and* depth of the tree is not really great either.  Ideally this should 
> work something like:
> 1. allocate a stack as char * array
> 2. push passed-in directory name onto stack
> 3. while(stack-not-empty):
>  a) create subpool
    it's more efficient to clear a loop_pool ...
>  b) pop top directory off stack
>  c) open directory and loop through entries:
>   i) for a directory, pop it on the stack
>   ii) for anything else, delete it
>  d) delete subpool
> (not sure whether processing the tree in FILO order or FIFO order is 
> better, I'd guess FIFO)
when we find a subdir we stop reading the current dir and recursively
delete the subdir. when we finish deleting the subdir, we start reading
the former dir again. FIFO.
> joe

Best regards,

Lucian Adrian Grijincu
Software Developer
Avira Soft srl


View raw message