On Aug 18, 2008, at 6:05 AM, Gopal V wrote:

>> I'll test the atomic functions out and add any additional bits I  
>> have to it in the next couple days.
>
> I just wanted no refcount++/-- for the update process - increments as
> you suggest would involve that, to prevent clobbering odd memory  
> during
> an expunge (and apc_inc in parallel, tiny window after the lock before
> the ++).

I'm not sure what you mean here, as the implementation I have did  
everything under lock so there was no refcount changes or windows for  
this to happen in after a lock.  Perhaps you had something else in  
mind when I said I was implementing atomic operations, or maybe I'm  
missing your point.  Either way I'll see if there's any differences  
worth keeping is mine, there's downsides and upsides to both of the  
implementations so I don't think It's worth doing anything too  
drastic to the implementation you currently have.

>
>> APCIterator code is all checked in now as well.
>
> It uses regex_t which is sort of being deprecated all over php land.
>

Right, I forgot about this.

> Here's a quick patch which uses pcre_* instead. And I notice that the
> iterator destroy leaks out the regex_t anyway (figuring it out for
> pcre is on my TODO list anyway).
>
> http://t3.dotgnu.info/code/apc_iterator_pcre.patch
>

THanks, this looks good to me.

> I'd like to remove the smart_str code in there and accept "/[0-9]0/"
> as a pattern into the iterator, so that everyone's clear that they
> have to escape slashes.

+1

>
> Pierre was rather pointed about ereg/regex_t usage (for the filters).
> And pcre is a core ext from 5.3 anyway.
>
>> I'm also thinking that it would probably be good to get Graham's  
>> optimizer item in as it's not user-facing or affecting anything  
>> that'll break.  Sounds like he's willing to make up a patch for it  
>> too.
>
> Yup, doing an "\0apc_compile_file" constant for him to check which
> ext was loaded first.

sweet.