Providing built-in functionality written in PHP (was RE: [PHP-DEV] [VOTE] UUID)
| From: | Zeev Suraski | Date: | Wed, 06 Sep 2017 12:46:19 +0000 |
| Subject: | Providing built-in functionality written in PHP (was RE: [PHP-DEV] [VOTE] UUID) | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-100417@lists.php.net to get a copy of this message | ||
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
From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
Sent: Wednesday, September 6, 2017 2:43 PM
To: Dan Ackroyd <danack@basereality.com>; internals@lists.php.net
Cc: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [VOTE] UUID
I'd seriously start considering to start doing PHP code for things like these, so they are not
bogged down by the fact that they are in C and there is 0.5 devs interested in supporting it.
On Wed, 6 Sep 2017, 14:09 Dan Ackroyd <danack@basereality.com<mailto:danack@basereality.com>> wrote:
On 5 September 2017 at 18:24, Fleshgrinder <php@fleshgrinder.com<mailto:php@fleshgrinder.com>> wrote:
> Maybe I should stop the vote. The discussion is happening now instead of
> before when I asked for it. We'll have to wait for at least six months
> for another vote if this is a no, due to the rules.
That would be fine and appropriate. The RFC targets 7.3. Having a
discussion and vote in March gives plenty of time for getting it into
7.3
Cancelling a vote just to avoid an RFC being rejected is (imo) playing
slightly fast and loose with the rules.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php