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