LMPX.COM :: shire :: Re: [APC-DEV] apc_delete

From: shire Date: Sat Jun 28 15:54:20 2008

Subject: Re: [APC-DEV] apc_delete_file() ?
Sorry for the delayed reply here, I didn't realize you had left a bunch
of good comments below here as well 8)

On Jun 9, 2008, at 11:53 AM, David Sklar wrote:

> 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.
>

I haven't done any micro benchmarks yet, but the usability performance
on doing a regex like /^whatever/ on a million user entries is much
better now that I've moved it into C.  I'm guessing this should be
enough for most uses, as I don't think too many people will have a
million files.  


> 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.

Initially I was thinking about expanding the current, next, etc type
functionality to allow iteration internally, but I like your idea of a
callback better.  Unfortunately, after thinking about locking and code
placement I'm a little nervous about going down the road of having
callbacks under a cache lock.  It would also mean reworking or
re-implementing some of the deletion functionality for the user cache
delete code as well.  I'll post my patch for comments in a second, take
a look and let me know what you think.  I opted for just creating a
delete function within the iterator code that can also be called from a
delete method later on (I didn't toss this in yet).  (iterator->delete()
would iterate it's stack, and apc_delete() just calls the iterator
method code internally) This makes both sides of the code a bit simpler,
take a look at my implementation under the existing delete function.  We
could optimize this and make it more atomic under a lock, but it starts
to get more messy than what I think anyone would be comfortable with at
this point. 

>
> 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.
>

I'm facing this problem with file updates as well as they aren't atomic
even if I'm holding a lock for the duration (as files can have
inter-dependencies between files that may or not be included in a
current request half way through it's include list).  I don't know if
it's a problem in practice yet, so we're going to try some things out
and see if it's a problem in a real world situation, so if you run into
these issues please let me know.  File deletion should be the same
problem just in reverse, as we're dealing with it from a
apc_compile_file perspective.


> 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.
>

Not sure on this one either way.  I like that it would probably be
easier on reflection and such, and probably easier coding wise than
dealing with a string.  But at the same time it's a departure from all
the existing API and it remains to be seen what happens with the
multi-cache code I'm working on that adds the ability for multiple file
and user caches. 


> -- 
> APC Development Mailing List (http://pecl.php.net/APC)
> To unsubscribe, visit: http://www.php.net/unsub.php
Navigate in group php.apc.dev at sever news.php.net
Previous	Next

© No Copyright You are free to use Anything	Site Maintained by PHP Developer Powered By PHP Consultants
From:	shire	Date:	Sat Jun 28 15:54:20 2008
Subject:	Re: [APC-DEV] apc_delete_file() ?