Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80351
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@tekwire.net>
To: "'Pierre Joye'" <pierre.php@gmail.com>,
	"'Derick Rethans'" <derick@php.net>,
	"'Dmitry Stogov'" <dmitry@zend.com>,
	"'Laruence'" <laruence@php.net>,
	"Sara Golemon" <pollita@php.net>
Cc: "'PHP internals'" <internals@lists.php.net>,
	"'Benjamin Eberlei'" <kontakt@beberlei.de>
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>
In-Reply-To: <CAEZPtU5ShKa9bMUOKsSuKjmEcXQZhsEUWrwNmsj2a_VSKSizEw@mail.gmail.com>
Date: Sun, 11 Jan 2015 05:38:29 +0100
Message-ID: <003c01d02d58$731d0cc0$59572640$@tekwire.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKBrOMj1TuM8+kkOgWpn3PeY833kwH7Ko95Akxyc6oB03YOjgM12LP/ApBySSma+EN1YA==
Content-Language: fr
Subject: RE: [PHP-DEV] [RFC] Extension Prepend Files
From: francois@tekwire.net (=?UTF-8?Q?Fran=C3=A7ois_Laupretre?=)

> 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 =
be
> modified ?
>=20
> 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 ?

> 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.

> As Sara pointed out , persistent opcode would be way better but as far
> as I remember it is something very tricky to do (due to how the
> address and offset are stored), maybe it changed now for 7, I did not
> check that part.

I remember we already discussed about PHP userspace code persistence =
years ago. What I remember most is that it was a nightmare with tons of =
side effects, but we were including PHP data persistence in the scope, =
which one more step towards hell. Maybe the core has evolved and things =
are easier now, especially in PHP7.

Anyway, from what I remember, Sara is the best one to design and =
implement an amazing solution in an amazingly short time (no flattery =
here :)

Regards

Fran=C3=A7ois