Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.192.48 as permitted sender)
Message-ID: <54D0F617.5040601@lerdorf.com>
Date: Tue, 03 Feb 2015 08:23:51 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: David Muir <davidkmuir@gmail.com>
CC: "francois@tekwire.net" <francois@tekwire.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <008b01d03f06$bc8e9940$35abcbc0$@tekwire.net> <54CFAAA5.6050700@lerdorf.com> <24F6AFBF-11C0-48C2-A923-87A79A475792@gmail.com>
In-Reply-To: <24F6AFBF-11C0-48C2-A923-87A79A475792@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="OvSQfI4KdWOTr1xfNIsprq4Lmq62q9p0x"
Subject: Re: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--OvSQfI4KdWOTr1xfNIsprq4Lmq62q9p0x
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/02/2015 07:35 PM, David Muir wrote:
>=20
>=20
>> On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>>
>>> On 02/02/2015 08:38 AM, Fran=C3=A7ois Laupretre wrote:
>>> Hi,
>>>
>>> Opening the vote for :
>>>
>>> https://wiki.php.net/rfc/streams-is-cacheable
>>>
>>> This RFC proposes a generic way for opcode caches to decide if a give=
n URI
>>> is cacheable or not.
>>
>> Doesn't this imply that "path" is the one true cache key? There are so=
me
>> issues with that which we will have to address at some point. For
>> example, when running fpm chrooted you need more than the path. We'll
>> likely need a more APC-like option here to use the device+inode for th=
e
>> key. It seems like a generic mechanism like you are proposing needs to=

>> take this into account and provide some mechanism that tells the opcod=
e
>> cache how to determine uniqueness. Perhaps that is simply encoded into=

>> the path parameter, but then maybe it should have a more appropriate n=
ame.
>>
>> -Rasmus
>>
>>
>=20
> 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 environ=
ment. Not sure if this is related to the issues you mean here...

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=
=2E

-Rasmus



--OvSQfI4KdWOTr1xfNIsprq4Lmq62q9p0x
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTQ9hcACgkQlxayKTuqOuD8WwCfcuSdc4kcMWoL1HHG5YTTmojp
qncAn2PXUUrSYridO4OCEeGcqBxYeIu5
=Q8/A
-----END PGP SIGNATURE-----

--OvSQfI4KdWOTr1xfNIsprq4Lmq62q9p0x--