Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100422
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.4 as permitted sender)
To: Zeev Suraski <vsuraski@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Arvids Godjuks <arvids.godjuks@gmail.com>,
 Dan Ackroyd <danack@basereality.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <BY2PR02MB2989D1A6035072A57D098DDAC970@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAF+90c-mHpF8N7tUiggUkO0m2Pxevz3OZ70TBKc1gFkZ2abzPQ@mail.gmail.com>
 <CAJHtznxHu3RzGbkmTj0K7ut+=cgaXNUwLo2kHzjVzecyOQqfCg@mail.gmail.com>
Message-ID: <d7cc2a67-be8d-91ea-a6ee-21abb5d7d412@tekwire.net>
Date: Wed, 6 Sep 2017 17:30:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAJHtznxHu3RzGbkmTj0K7ut+=cgaXNUwLo2kHzjVzecyOQqfCg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: fr
Subject: Re: [PHP-DEV] Providing built-in functionality written in PHP (was
 RE: [PHP-DEV] [VOTE] UUID)
From: francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi Zeev,


Le 06/09/2017 à 16:01, Zeev Suraski a écrit :
> Thanks for the pointer! I didn't pay close attention to that discussion
> back then. I do remember François brought it up in a discussion back in
> 2015 in Paris.
>
> For me the issue of security is a major benefit that I don't think was
> brought up in that discussion.  It's the killer feature as far as I'm
> concerned.

Sure. During the discussion, we focused on maintainability but increased 
security is a key benefit too.

> For those who mentioned that PHP code is better managed in Composer - I
> think we're talking about different layers here.  The goal wouldn't be
> pulling in things from the framework layers into the PHP layer, but being
> able to surgically replace existing implementations that could benefit from
> being written in PHP - as well as potentially some very basic non-complex
> building blocks that change very infrequently if at all.  I don't really
> know, but I'm guessing the challenge experienced by MongoDB probably had to
> do with the fact this was a pretty big & complex extension as well as one
> that evolves and changes pretty frequently - the kind of which is probably
> still better served in C code (or alternatively, a Composer based package).

The discussion made clear that the feature has nothing to do with 
composer, and I hope everyone now agrees on this.

> PCS seems to be a huge step in the direction I think we need to take,
> although I think we probably need to push it further a couple of notches.

My primary constraint, with PCS, was to implement it as a pure 
extension, without modifying anything in the core. But the discussion 
made clear that, when the feature exists, making it optional is useless. 
That's why I am currently working on a new version, as an extension too, 
but a mandatory one, included in the PHP core.

> First, offhand, I don't think autoloading should play a role.  We should
> create a mechanism where the PHP-based code is at the exact same level as
> C-based code, i.e., it's available the whole time, including
> function_exists(), indirect reference and whatnot.  In order to achieve
> that with good performance we probably need to find a way to compile all
> the different built-in PHP elements in one go so that they fit into one
> 'virtual include' that can be easily and quickly made available to all
> requests.  I don't think PCS currently supports that, but I'm pretty sure
> we can achieve that.

I also gave up with the autoloader. If functions could be autoloaded, it 
could be worth going further, but this is definitely not the right 
mechanism to base it on.

So, help is welcome here. Currently, my plan is to use opcache to 
persist the code and load it when needed. I already have the stream 
wrapper, virtual paths... Combining this with 'fake' function entries 
should allow to load it just in time. Well, this requires more 
investigation... Another approach would be to compile the code during 
MINIT and make it persistent outside of opcache. If you have more ideas 
about it, they are appreciated.

> Secondly, ideally, this shouldn't just be a mechanism to mix and match C
> and PHP - but actually make it easy for people to write pure PHP code
> that'll become integrated to the PHP binary.  PCS can practically already
> support that, we'd just need some build magic to take .php files during
> build, create the PCS wrapper for them and compile them right in.  Have
> some sort of a standard where builtin.php files inside extension
> directories are included, or something of the sort?  Definitely requires
> more thinking, but if this becomes a basic building block of PHP as I think
> it should, I wouldn't want end users to have to manually compile PHP code
> into .phpc or create .c wrappers - but have it as automatic as possible.

Parsing the code, extracting symbol names, and generating all needed 
information as a C include file is done offline because it requires a 
working PHP interpreter. So, it cannot be done at build time (when 
compiling the core). It is done the same way as the core files generated 
using PHP (like zend_vm_execute.h/zend_vm_opcodes.h): each time, he 
modifies the PHP code, the developer must regenerate the '.phpc' files. 
The '.phpc' file will be managed in git and will be included in the 
source distribution. So, nothing changes for the end user : 
phpize/configure/make. The same for extensions included in the core: 
'.phpc' files are included in the source distrib. I'll also probably 
include this code (re)generation in 'phpize'.

So, the most difficult part, AFAIK, is how to make class and function 
code persistent, or load it just in time, or a combination of both. The 
case of constants is more complex and out of scope at this time. I hope 
I have some times during the next weeks to implement a prototype, at 
least for functions.

Regards

François