On Wed, Sep 6, 2017 at 4:19 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, Sep 6, 2017 at 2:46 PM, Zeev Suraski <z...@zend.com> wrote: > > > I think that actually makes a lot of sense, and not just because of the > > supportability – but also because of security. A whole class of security > > exploits – buffer/stack overflows, underruns and all sorts of memory > > mismanagement become irrelevant when the code is implemented in PHP. I > > brought this direction up in a discussion on the Security mailing list a > > few weeks ago without any traction – but it probably makes more sense to > > discuss it here anyway. > > > > I think that currently, there are two main challenges: > > > > 1. Performance – compute intensive logic is way slower in PHP compared > > to C. > > 2. Delivery method – we don’t currently have a good way of providing > > functions that are written in PHP and have them provide the same > ‘native’ / > > ‘builtin’ experience as functions/classes written in C. > > > > Regarding #1, often this isn’t very important as not all pieces of code > > are that compute intensive. Moreover, if/when JIT materializes, compute > > intensive logic in PHP will become a lot faster than it is today and > > probably in the same ballpark as C – so it’ll open the door for us > > implementing more and more things in PHP. > > > > Regarding #2 – I think that’s something that can be solved relatively > > easily, but admittedly I haven’t completely thought it through (read: I > > barely thought about it). > > > > We could create a mechanism where the contents of certain .php files is > > embedded into the binary, compiled during MINIT, and made available > pretty > > at the same ‘builtinness’ level as C extensions. We’d probably have to > be > > pretty selective in terms of what goes in there – probably just as > > selective as we are with the C-based extensions, but I’d imagine that > > things like ext/exif, UUID, and perhaps even things like unserialize() > > could find themselves written in pure PHP using such a mechanism. > > > > Thoughts? > > > > Zeev > > > > There has been a discussion about this recently: > https://externals.io/message/99366 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. 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). 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. 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. 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. Zeev
