Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48877 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75167 invoked from network); 21 Jun 2010 03:05:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2010 03:05:03 -0000 Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.212.42 cause and error) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:52524] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/1A-15307-DD6DE1C4 for ; Sun, 20 Jun 2010 23:05:02 -0400 Received: by mail-vw0-f42.google.com with SMTP id 16so929127vws.29 for ; Sun, 20 Jun 2010 20:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.31 with SMTP id y31mr1628610vcl.174.1277089501437; Sun, 20 Jun 2010 20:05:01 -0700 (PDT) Received: by 10.220.70.202 with HTTP; Sun, 20 Jun 2010 20:04:56 -0700 (PDT) In-Reply-To: <4C1ED20E.8050805@sugarcrm.com> References: <4C1EA662.1010601@sugarcrm.com> <49B64FA1-1BAA-4C88-AC9D-09E75792F05C@seancoates.com> <4C1ED20E.8050805@sugarcrm.com> Date: Sun, 20 Jun 2010 23:04:56 -0400 Message-ID: To: Stas Malyshev Cc: Sean Coates , PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] APC in trunk From: ilia@prohost.org (Ilia Alshanetsky) Stas, Even if the extension is compiled by default, we can (and probably should) leave apc.enabled at Off, recognizing some the things you are mentioning. On Sun, Jun 20, 2010 at 10:44 PM, Stas Malyshev wrote: > Hi! > >> Can you elaborate? What "average user"-facing features are non-obvious? >> We should document them if nothing else. > > This recently caught my attention: http://pecl.php.net/bugs/bug.php?id=16745 > As I understood from this bug, APC changes how PHP works (since it works > without APC but not with it) and it is not considered a problem in APC. > Which means enabling APC by default is a BC break, and there's already a > proof that it breaks real-life code (even if particular code had been > changed to work with it, the fact that APC can break otherwise working code > stays). Now probably most of the experienced users wouldn't mind fixing the > code a bit, but for enabling by default it should be 100% BC. > > apc.file_update_protection could have some unexpected results too. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >