Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12624 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27504 invoked by uid 1010); 7 Sep 2004 04:06:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 21731 invoked from network); 7 Sep 2004 04:05:24 -0000 Received: from unknown (HELO colo.lerdorf.com) (66.198.51.121) by pb1.pair.com with SMTP; 7 Sep 2004 04:05:24 -0000 Received: from [192.168.1.104] (c-24-6-200-247.client.comcast.net [24.6.200.247]) by colo.lerdorf.com (8.13.1/8.13.1/Debian-11) with ESMTP id i8745KGu020417; Mon, 6 Sep 2004 21:05:20 -0700 Date: Mon, 6 Sep 2004 21:05:19 -0700 (PDT) X-X-Sender: rasmus@t42p To: Xuefer cc: internals@lists.php.net, Russ Garrett In-Reply-To: Message-ID: References: <20040905193319.91641.qmail@pb1.pair.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Really odd PHP problem From: rasmus@php.net (Rasmus Lerdorf) 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