I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload
Overall, big +1.
A few questions:
- "Only classes without unresolved parent, interfaces, traits and
constant values may be preloaded." Is this determined at the moment of
an individualopcache_compile_file()? Or can mis-ordered includes
resolve themselves upon later compiles? e.g. I compile a.php with
class A extends B {}, then subsequently compile b.php withclass B {}. The engine has enough information to resolve this, even if it
wasn't presented in an ideal order.
We try to resolve dependencies among classes in all preloaded scripts, using iterative fixed-point approach.
- Will we raise warnings explaining why a given class is being
deferred from pre-loading to help users understand how to use this
correctly?
Yes. This is already done.
- "Preloading may be used as systemlib in HHVM to define “standard”
functions/classes in PHP" Presumably the internal APIs will be defined
to handle this at the script level already. What stops us from simply
ZENDAPIing the proto and letting extensions call it if they want?
((Simple conservatism is an adequate answer, but I'd like to know why
it's out of scope)).
I didn't understand what you propose.
- "In conjunction with ext/FFI (dangerous extension), we may allow
FFI functionality only in preloaded PHP files, but not in regular
ones." Is there any interest in something like HHVM's HNI interface?
FFI always sounds nice in theory, but complex types mean that a little
bit of glue code is often a plus.
Did you see FFI PoC? https://github.com/dstogov/php-ffi
Thanks. Dmitry.
I'll try to fix this in nearest week(s).
Thank you for everything you do.
-Sara
I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload
- "In conjunction with ext/FFI (dangerous extension), we may allow
FFI functionality only in preloaded PHP files, but not in regular
ones." Is there any interest in something like HHVM's HNI interface?
FFI always sounds nice in theory, but complex types mean that a little
bit of glue code is often a plus.
As always when it comes to PHP and FFI I'd like to point out ext-psi [1]
which uses a different approach than other PHP FFIs until now.
It parses PSI files at startup, which basically are C header files
augmented with the PHP userland interface decls, see for example the PSI
file for time.h [2]
As you can see, marshalling from and to native types has been taken
seriously, and while we're capable of recursively unmarshalling e.g.
addrinfo structs [3] and handling sqlite callbacks [4] it's still not
possible yet for something like curl_easy_setopt.
[1] https://github.com/m6w6/ext-psi
[2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi
[3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70
[3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt
--
Regards,
Mike
I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload
- "In conjunction with ext/FFI (dangerous extension), we may allow
FFI functionality only in preloaded PHP files, but not in regular
ones." Is there any interest in something like HHVM's HNI interface?
FFI always sounds nice in theory, but complex types mean that a little
bit of glue code is often a plus.As always when it comes to PHP and FFI I'd like to point out ext-psi [1]
which uses a different approach than other PHP FFIs until now.It parses PSI files at startup, which basically are C header files
augmented with the PHP userland interface decls, see for example the PSI
file for time.h [2]As you can see, marshalling from and to native types has been taken
seriously, and while we're capable of recursively unmarshalling e.g.
addrinfo structs [3] and handling sqlite callbacks [4] it's still not
possible yet for something like curl_easy_setopt.[1] https://github.com/m6w6/ext-psi
[2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi
[3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70
[3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56
[4] https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt
hi Michael,
You made a great job developing ext-psi.
But anyway, I more like my own FFI implementation (at least because it's
simpler and it's mine).
FFI::load() in conjunction with preloading, would provide functionality
similar to PSI files loading on startup.
In the future, I would like to push ext/FFI into core and integrate it
with JIT (similar to LuaJIT way).
In any case, this thread is about preloading, that is interesting by
itself. FFI and JIT are the future scope.
Thanks. Dmitry.
Just a side question: will the information on preloaded userland classes
and functions be available via php --rc / php --rf commands?
I would like to start discussion on a Preloadng RFC
https://wiki.php.net/rfc/preload
- "In conjunction with ext/FFI (dangerous extension), we may allow
FFI functionality only in preloaded PHP files, but not in regular
ones." Is there any interest in something like HHVM's HNI interface?
FFI always sounds nice in theory, but complex types mean that a little
bit of glue code is often a plus.As always when it comes to PHP and FFI I'd like to point out ext-psi [1]
which uses a different approach than other PHP FFIs until now.It parses PSI files at startup, which basically are C header files
augmented with the PHP userland interface decls, see for example the PSI
file for time.h [2]As you can see, marshalling from and to native types has been taken
seriously, and while we're capable of recursively unmarshalling e.g.
addrinfo structs [3] and handling sqlite callbacks [4] it's still not
possible yet for something like curl_easy_setopt.[1] https://github.com/m6w6/ext-psi
[2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi
[3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70
[3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt
[4]
https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56
[4]
https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpthi Michael,
You made a great job developing ext-psi.
But anyway, I more like my own FFI implementation (at least because it's
simpler and it's mine).FFI::load() in conjunction with preloading, would provide functionality
similar to PSI files loading on startup.In the future, I would like to push ext/FFI into core and integrate it
with JIT (similar to LuaJIT way).In any case, this thread is about preloading, that is interesting by
itself. FFI and JIT are the future scope.Thanks. Dmitry.
--
--
Best regards,
Victor Bolshov