Re: Really odd PHP problem

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" <rasmus@php.net> To: "Xuefer" <Xuefer@hotmail.com> Cc: <internals@lists.php.net>; "Russ Garrett" <russ@last.fm> 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 > >