Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57227 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26977 invoked from network); 5 Jan 2012 07:50:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2012 07:50:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=laruence@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=laruence@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender) X-PHP-List-Original-Sender: laruence@gmail.com X-Host-Fingerprint: 209.85.220.170 mail-vx0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:35213] helo=mail-vx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/E4-28877-E36550F4 for ; Thu, 05 Jan 2012 02:50:24 -0500 Received: by vcdn13 with SMTP id n13so206213vcd.29 for ; Wed, 04 Jan 2012 23:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/UcMpW0f8eZutLrCvRh0d56xRXqlFZuz1oWAW951HBE=; b=wfbUNX45Q5DyCOHyrm97NevmLMTrM7ez+ZU8mFGw7kc57K4fPwAGk7Ja77x+D7rAvu GGgI7X+GZ3eXBehhYBr3gau/UiRT55SNXAr23qwI4otaRtfSkulehHlOUnNJRQQ/ORrL p3frwj889lYC1UbUWmyyyQ0EVmtcp95ZzfP/g= Received: by 10.220.149.10 with SMTP id r10mr492006vcv.38.1325749820266; Wed, 04 Jan 2012 23:50:20 -0800 (PST) MIME-Version: 1.0 Sender: laruence@gmail.com Received: by 10.220.3.14 with HTTP; Wed, 4 Jan 2012 23:49:59 -0800 (PST) In-Reply-To: <4F055238.1070605@sugarcrm.com> References: <4F048A03.4070408@sugarcrm.com> <4F04A172.7080509@sugarcrm.com> <4F04AA8E.6020701@sugarcrm.com> <4F04AD6D.80608@php.net> <4F04B071.8080102@php.net> <4F04B44D.6080208@thelounge.net> <4F04BCF9.30802@lerdorf.com> <4F04BF63.5060309@lerdorf.com> <4F04C427.9050202@sugarcrm.com> <4F04C920.9050105@lerdorf.com> <4F04CB0D.6040703@lerdorf.com> <4F054CB0.6070202@sugarcrm.com> <4F05517C.5040600@lerdorf.com> <4F055238.1070605@sugarcrm.com> Date: Thu, 5 Jan 2012 15:49:59 +0800 X-Google-Sender-Auth: QrCQmYFTPr2o2s_sKSen9C4UAi8 Message-ID: To: Stas Malyshev Cc: Rasmus Lerdorf , Ferenc Kovacs , Reindl Harald , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: another fix for max_input_vars. From: laruence@php.net (Laruence) Hi: there is one way maybe is a good try. when resize hashtable, we don't just dobule the size, instead, we increase the hashtable size with a random delta what do you think? thanks On Thu, Jan 5, 2012 at 3:33 PM, Stas Malyshev wrot= e: > Hi! > > >> Yes, but we still need an actual case to look at. Opcode caches >> shouldn't be a problem unless they store some representation on disk >> that live across server restarts. In the APC world, nobody does that. Is > > > It's not that simple. Take example of FastCGI setup where processes can l= ive > and die independently (note that FastCGI does not mandate single-parent f= ork > and in fact on Windows it doesn't work that way). In this setup opcode ca= che > is shared between processes which may have different hash value, unless w= e > give means to the cache to set this value on startup somehow. > > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --=20 Laruence =C2=A0Xinchen Hui http://www.laruence.com/