Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <003c01d02d58$731d0cc0$59572640$@tekwire.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAEZPtU5M_NdtZ-e_48Ce5Rjb1KKHkzDMrqLD5sx-WwDctR7u5Q@mail.gmail.com>
	<001501d02ccc$574a6bf0$05df43d0$@tekwire.net>
	<CAEZPtU73+y4AJ9BfACmYuBe79+Ls-A-yQSZhxUoTi3m8KTQEMQ@mail.gmail.com>
	<000a01d02cf8$ab090130$011b0390$@tekwire.net>
	<CAEZPtU5ShKa9bMUOKsSuKjmEcXQZhsEUWrwNmsj2a_VSKSizEw@mail.gmail.com>
	<003c01d02d58$731d0cc0$59572640$@tekwire.net>
Date: Sat, 10 Jan 2015 21:33:54 -0800
Message-ID: <CAEZPtU6kerXq9z+i6jtn26JUnLgM1imMXasKD6iH14Q7cvDgow@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Dmitry Stogov <dmitry@zend.com>, Sara Golemon <pollita@php.net>, Laruence <laruence@php.net>, 
	Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>
Content-Type: multipart/alternative; boundary=047d7b3a829e5a2f48050c59bc37
Subject: RE: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

--047d7b3a829e5a2f48050c59bc37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jan 11, 2015 11:38 AM, "Fran=C3=A7ois Laupretre" <francois@tekwire.net> =
wrote:
>
> > De : Pierre Joye [mailto:pierre.php@gmail.com]
> >
> > > Sorry, I am not sure I understand how the opcode cache, as it exists
now,
> > can understand this. Do you mean that opcode cache code would need to b=
e
> > modified ?
> >
> > Yes and no. Yes if we want them to do not even try to update files
> > that are statically built in extensions. And yes, if we want that (for
> > whatever reasons I cannot think about right now).
>
> Sorry, it must be too late :)
>
> AFAIR, the opcode cache attempts a stat() call on the filename it
receives to get its mtime and use it to determine if file was modified
since it was cached. I don't understand how an opcode cache can do a stat()
on the filename you provide as, without a stream wrapper, there is no way
to access such information (which doesn't even have any sense here). Your
filename will be recognized as a plain filename, the libc stat() call will
look for this filename in the current directory, it won't be found, and
opcode caching will fail. If the file doesn't have an associated
stream-wrapped path, you cannot issue a stat() on it and I don't see how it
can be cached. Where am I wrong ?

Say we do support builtin scripts, an opcache will simply load them on
minit or on the first request and flag them as permanent. Yes, it means we
need to change opcache but could be way easier than trying to hack the
engine to support persistent Opcodes without ending with ... an opcache.

> > That's PHP7, we can and have already broken BC internally.
>
> So, you confirm that opcache is the only supported opcode cache in PHP 7
? That's a good thing. I know that PHP7 breaks BC, I just wanted to know if
developments in this branch had to remain compatible with APC and friends.

It is almost already the case for 5.5+, apc is dead for anything >=3D 5.5

--047d7b3a829e5a2f48050c59bc37--