Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81730 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46024 invoked from network); 3 Feb 2015 19:02:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Feb 2015 19:02:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=francois@tekwire.net; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=francois@tekwire.net; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@tekwire.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:25088] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/85-20608-F3B11D45 for ; Tue, 03 Feb 2015 14:02:24 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 978A74B02A8; Tue, 3 Feb 2015 19:59:07 +0100 (CET) Reply-To: To: "'Rasmus Lerdorf'" , "'David Muir'" Cc: References: <008b01d03f06$bc8e9940$35abcbc0$@tekwire.net> <54CFAAA5.6050700@lerdorf.com> <24F6AFBF-11C0-48C2-A923-87A79A475792@gmail.com> <54D0F617.5040601@lerdorf.com> In-Reply-To: <54D0F617.5040601@lerdorf.com> Date: Tue, 3 Feb 2015 20:02:17 +0100 Message-ID: <006b01d03fe3$ee2088a0$ca6199e0$@tekwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFX7Xg2OtZN3lyuxp3N4vgO3eqARwHgw/C+ArQiQNcCpmBLZp2WBkmg Content-Language: fr X-Antivirus: avast! (VPS 150203-0, 03/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation From: francois@tekwire.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) > De : Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > > Don't we already have this problem with chrooted FPM? I haven't = tested it > more recently, but last time I tried, opcache would fail to invalidate = the cache > after updating the file. Worked fine with a non-chroot environment. = Not > sure if this is related to the issues you mean here... >=20 > Yes, like I said, this is an issue we have to address still. It is on > the TODO list and definitely looking for volunteers. I just wanted to > make sure that Francois' RFC didn't introduce something which would = make > it harder to eventually fix this by not allowing for a non-path cache = key. Well, from what I see in accel_make_persistent_key_ex(), the key is the = path or a concatenation of the path, the cwd, the include path... Of = course, the idea is to avoid the stat() call. But I don't see how we can = determine a reliable cache key without a stat(). Maybe opcache shouldn't compute the key by itself. For each file it = receives, it would ask the corresponding wrapper for a cache key (and = the plain files wrapper would do a stat() and return dev/inode/mtime). Fran=C3=A7ois