From:	David Sklar	Date:	Mon Jun  9 12:53:32 2008
Subject:	Re: [APC-DEV] apc_delete_file() ?

I haven't tested the relative performance of the prefix vs. glob vs.
regex modes of my patch. My initial interest is just in the prefix
stuff, so in particular, the perf of prefix (via strncmp) and prefix
(via regex /^whatever/) would be most relevant, I suppose.

On Thu, May 29, 2008 at 3:01 PM, shire <shire@tekrat.com> wrote:
> [ ...  APCIterator stuff ... ]
>
> I'm thinking that deletes could then possibly look something like:
>
> $it = new APCIterator('file', '^/some/path/');      // fetch all files
> starting with /some/path
> apc_delete_files($it);                              // delete all those, as
> apc_delete_files knows how to work with APCIterator class
>
> apc_delete_files('/one/specific/file.php');         // delete a single
> specific file a as a string name
>
> apc_delete_files(array('file1.php', 'file2.php'));  // delete an array of
> specific file names
>
>
> If we do need more options like globs and prefix etc, then it might be
> preferred if they go into the iterator so it can be used for other features,
> etc.  The downside of all this is that it's actually slower than just
> passing the regex directly into apc_delete_files as you're looking
> everything up twice.  Alternatively it could just become a glorified
> container for the regular expressions/matching mechanism as well.  I do tend
> to prefer this interface however, but what are other's thoughts on this?

I like the APCIterator interface, both for deleting entries but also
for the other mechanisms you propose (pushing the entry-selection
special cases into it, etc.)

I think we can use it and not have the double lookups, if APCIterator
and functions that use it are intertwined appropriately. That is, the
flow for something like this:

$It = new APCIterator('file','^/my/directory/');
apc_delete_files($it);

Could be, internally, something like this:

- Iterator construction just compiles regex
- apc_delete_files passes a callback function to a "walk" method in
the iterator. The walk method locks the cache, walks through
chunk_size slots at a time, invokes the callback on each slot, unlocks
the cache; It repeats this for each chunk of slots.

Then, other user-level functions that interact with the iterator in
the future would just pass different callback functions into the
walker.

Like you said, the operations would not be atomic across the entire
cache but if that needs to be forced, the caller can specify the cache
size as the chunk_size.

How do you feel about removing the first param to APCIterator
constructor and instead splitting the user-level interface into
APCFileIterator and APCUserIterator classes? Functionally equivalent,
but would make runtime introspection and typo-prevention easier.