On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> So I think it would be useful to define what exactly would be covered
> and what not, i.e. which APIs are supported, which can be supported,
> which can not. Right now we don't even have the API as such for the
> engine itself (i.e., you can just go to EG(...) or bits of the zval and
> mess with them, and not only you can but many extensions do).
>
My idea is to cover *most* (but not all) extensions with a narrower,
simplified API. As you say, many interactions fall into the "marshal
this engine value to a C type as needed". This can cater to the
bread-and-butter of PHP extensions very well.
I'd want to export something like the Z_TYPE/Z_*VAL style macros (or a
variant thereof, maybe... dare I say it "pval" based?),
zend_(hash|symtable)_*() APIs (though maybe more like the add_*() APIs
and the array_*() APIs I proposed a year or so ago for dealing with
arrays. obj_(read|write)_(dim|prop)(), invoke_(func|method)() for
calling into userspace, etc...
To cover the least-common denominator, it'd have to be a C api, but in
my perfect world we offer a C++ api alongside it. I can't tell you
how much more enjoyable HHVM's array API is. int total =
arr["v1"].toInt64() + arr["v2"].toInt64(); versus... well, you know
how many lines that'd take in a PHP extension... Keeping these in
sync doesn't have to be difficult since one can call through the
other. Add some inline hinting and it doesn't even need to be
expensive.
As for reaching deep into the engine, I think we can just offer better
APIs. So like, where exts currently use EG(function_table), they can
use function_invoke_named("strtolower", arg1, arg2, arg3); or f =
function_find("strtolower"); function_invoke(f, arg1, arg2, arg3);
for cachable functions. In the API layer, typeof(f) is a php_function
which translates to a struct of zend_fcall_info/zend_fcall_info_cache
for PHP, or HPHP::Func* for HHVM. (As an example)
Similarly EG(symbol_table)/EG(active_symbol_table) can hide behind
either table = symbol_table_get(LOCAL|GLOBAL); array_set_value(table,
"foo", pval); or maybe something more specific like
symoltable_set_value("foo", pval, LOCLA|GLOBAL);
And on and on and on for other EG() style accesses. I don't think we
need to try to address deep engine elements like
EG(current_execute_data) (or whatever it's called, it's been awhile...
:p). There's a line in there somewhere that we can say "for this,
just reach behind the scenes, but you'll need to fix your stuff from
version to version and all the #ifdefs that entails". Like... I don't
think we need to support runkit, for example. :)
> Also I wonder how that would sit with phpng effort. Lately it was very
> focused on performance-based optimizations, and working via abstract
> APIs may not be always the most performant way of doing things.
>
It's PHPNG that makes this more possible since the structure of the
PHP7 zval is so much closer to what HHVM has been doing with
TypedValue. It's possible to make an abstraction which knows how to
talk to those two, at least, without either having to suffer for it.
Similarly, request-local variables are much more similar now that
tsrm_ls is gone. It's PHPNG that makes such a compatibility
abstraction possible. Yes, we'll need to be very careful not to hurt
performance for either implementation. That would suck and I would
get my butt kicked by both sides. I don't want my butt kicked.
>> learn from. Heck, we're actually halfway there with HHVM's
>> "ext_zend_compat" layer, which makes PHP extensions (mostly) source
>> compatible with HHVM.
>
> Is there some docs for what ext_zend_compat does and which APIs it
> supports/doesn't support?
>
No, building a PHP ext against HHVM just sort of "does" or "does not"
work. The source is under hphp/runtime/ext_zend_compat if you're
curious. The general idea is that it re-exports ZendEngine's headers,
implementing some C apis, defining/inlining others where possible.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
