Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-mHpF8N7tUiggUkO0m2Pxevz3OZ70TBKc1gFkZ2abzPQ@mail.gmail.com>
References: <BY2PR02MB2989D1A6035072A57D098DDAC970@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAF+90c-mHpF8N7tUiggUkO0m2Pxevz3OZ70TBKc1gFkZ2abzPQ@mail.gmail.com>
Date: Wed, 6 Sep 2017 17:01:51 +0300
Message-ID: <CAJHtznxHu3RzGbkmTj0K7ut+=cgaXNUwLo2kHzjVzecyOQqfCg@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="94eb2c032d9a2858b1055885c94c"
Subject: Re: [PHP-DEV] Providing built-in functionality written in PHP (was
 RE: [PHP-DEV] [VOTE] UUID)
From: vsuraski@gmail.com (Zeev Suraski)

--94eb2c032d9a2858b1055885c94c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 6, 2017 at 4:19 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Wed, Sep 6, 2017 at 2:46 PM, Zeev Suraski <zeev@zend.com> wrote:
>
> > I think that actually makes a lot of sense, and not just because of the
> > supportability =E2=80=93 but also because of security.  A whole class o=
f security
> > exploits =E2=80=93 buffer/stack overflows, underruns and all sorts of m=
emory
> > 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 =E2=80=93 but it probably makes more=
 sense to
> > discuss it here anyway.
> >
> > I think that currently, there are two main challenges:
> >
> >   1.  Performance =E2=80=93 compute intensive logic is way slower in PH=
P compared
> > to C.
> >   2.  Delivery method  =E2=80=93  we don=E2=80=99t currently have a goo=
d way of providing
> > functions that are written in PHP and have them provide the same
> =E2=80=98native=E2=80=99 /
> > =E2=80=98builtin=E2=80=99 experience as functions/classes written in C.
> >
> > Regarding #1, often this isn=E2=80=99t very important as not all pieces=
 of code
> > are that compute intensive.  Moreover, if/when JIT materializes, comput=
e
> > intensive logic in PHP will become a lot faster than it is today and
> > probably in the same ballpark as C =E2=80=93 so it=E2=80=99ll open the =
door for us
> > implementing more and more things in PHP.
> >
> > Regarding #2 =E2=80=93 I think that=E2=80=99s something that can be sol=
ved relatively
> > easily, but admittedly I haven=E2=80=99t 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 =E2=80=98builtinness=E2=80=99 level as C extensions.   We=
=E2=80=99d probably have to
> be
> > pretty selective in terms of what goes in there =E2=80=93 probably just=
 as
> > selective as we are with the C-based extensions, but I=E2=80=99d imagin=
e 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=C3=A7ois brought it up in a discussion back i=
n
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

--94eb2c032d9a2858b1055885c94c--