thanks for your taking care of my bug reports
my optimizer patch is in http://pecl.php.net/bugs/bug.php?id=1678
i guess u've saw it just now. the changes required by the fix isn't that much as my 
patch.
i reorgnized the blocks of code into macro(i personally don't like too much boring 
repeats),
this should make it easy to update and less mistakes. i don't knw it this breaks any 
coding rules.
feel free to keep origin struct but make the changes careful :)

the mose unstable code is doing constant_fold.
IIRC, long ago, ZendEngine disabled static computeValue:

php -r 'function a(){static $a=1+1;}'
Parse error: parse error, expecting `','' or `';'' in Command line code on line 1

to avoid being unstable(crash?)

i wonder why mmcache managed to do it.
how about other optimizers?


----- Original Message ----- 
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "Xuefer" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Russ Garrett" <[EMAIL PROTECTED]>
Sent: Tuesday, September 07, 2004 12:05 PM
Subject: Re: [PHP-DEV] Really odd PHP problem


> On Tue, 7 Sep 2004, Xuefer wrote:
>> APC works with apache2 DSO, and the optimizer is stable ONLY with my patches
>> check it out here: 
>> http://pecl.php.net/bugs/search.php?cmd=display&status=Open&bug_type[]=APC
>> i've used APC from the time my last patch posted till now, having 0 crash. (if i 
>> clear the cache after long time running, about 1/10 chance will get crash)
>> FYI: my script seems never beyond cache size
> 
> I have fixed a number of problems related to running out of shared memory
> in APC lately.  If you grab the current CVS version I think you will find
> that it is less likely to fill up shared memory, and when it does, it is
> smarter about handling that scenario when it happens.
> 
> I really haven't done much to the optimizer.  I tend to just leave it off.
> I would be interested in seeing your patches.
> 
>> both mmcache and apc does not have "crash recover"
> 
> The concept of a crash recover is somewhat flawed in my opinion.  The only
> way to really do this is to catch SIGSEGV, SIGBUS and other such fatal
> signals and twiddle a knob somewhere in shared memory that tells other
> processes to flush the cache.  The problem with doing this is that once
> you get a SEGV, it really isn't safe to do anything like that.  You run a
> very serious risk of ending up in an infinite crash loop where you catch
> the crash, try to set the crash-recover flag, crash trying to do that,
> catch the crash, etc.
> 
> -Rasmus
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

Reply via email to