Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48883 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85418 invoked from network); 21 Jun 2010 03:32:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2010 03:32:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.203 smtp203.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.203] ([67.192.241.203:44704] helo=smtp203.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/4C-15307-85DDE1C4 for ; Sun, 20 Jun 2010 23:32:40 -0400 Received: from relay20.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C249821280E0; Sun, 20 Jun 2010 23:32:37 -0400 (EDT) Received: by relay20.relay.dfw.mlsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 572AA2128095; Sun, 20 Jun 2010 23:32:37 -0400 (EDT) Message-ID: <4C1EDD54.6030109@sugarcrm.com> Date: Sun, 20 Jun 2010 20:32:36 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Rasmus Lerdorf , PHP Internals References: <4C1EA662.1010601@sugarcrm.com> <49B64FA1-1BAA-4C88-AC9D-09E75792F05C@seancoates.com> <4C1ED20E.8050805@sugarcrm.com> <4C1ED846.90108@lerdorf.com> In-Reply-To: <4C1ED846.90108@lerdorf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] APC in trunk From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is an unfixed PHP bug. There have been a number of threads about > the object destruction order on internals. It isn't just APC that is > affected by this. Other extensions are affected as well. I understand that this effect is caused by the fact that APC destroys PHP classes earlier than PHP engine otherwise would. You can claim it's a bug but then until it's fixed enabling APC would still cause BC break, and no amount of renaming this fact would change it. If we can fix it and make it work properly - fine, then this ojection ceases to exist as soon as it's done, if there's no more cases when APC behaves differently. >> apc.file_update_protection could have some unexpected results too. > > Not any that change the behaviour of PHP. Do I misunderstand how this feature works? I was under impression that it prevents APC from updating the file for X seconds since its modification - while plain PHP of course would see the change instantly. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227