Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57228 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28311 invoked from network); 5 Jan 2012 07:55:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2012 07:55:21 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.170 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:43763] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 04/35-28877-767550F4 for ; Thu, 05 Jan 2012 02:55:20 -0500 Received: by iafj26 with SMTP id j26so578758iaf.29 for ; Wed, 04 Jan 2012 23:55:17 -0800 (PST) Received: by 10.43.131.196 with SMTP id hr4mr832269icc.55.1325750116914; Wed, 04 Jan 2012 23:55:16 -0800 (PST) Received: from [192.168.200.5] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPS id z22sm198560288ibg.5.2012.01.04.23.55.15 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 23:55:16 -0800 (PST) Message-ID: <4F055762.9020508@lerdorf.com> Date: Wed, 04 Jan 2012 23:55:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Stas Malyshev CC: Laruence , Ferenc Kovacs , Reindl Harald , "internals@lists.php.net" References: <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> <4F052C10.30106@lerdor f.com> <4F054CB0.6070202@sugarcrm.com> <4F05517C.5040600@lerdorf.com > <4F055238.1070605@sugarcrm.com> In-Reply-To: <4F055238.1070605@sugarcrm.com> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: another fix for max_input_vars. From: rasmus@lerdorf.com (Rasmus Lerdorf) On 01/04/2012 11:33 PM, Stas Malyshev wrote: > 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 > live and die independently (note that FastCGI does not mandate > single-parent fork and in fact on Windows it doesn't work that way). In > this setup opcode cache is shared between processes which may have > different hash value, unless we give means to the cache to set this > value on startup somehow. hrm, ok, yes for non single parent forks it is an issue. For APC there is no such thing, although people have been asking for it. With a clean API this doesn't sound insurmountable though. get_hash_seed()/set_hash_seed() internal functions. When the cache is created the first time call get_hash_seed() and store it somewhere. When someone connects to an existing cache the first time, fetch the stored hash seed and call set_hash_seed() -Rasmus