Re: PHP FFI extenesion
| From: | Dmitry Stogov | Date: | Thu, 26 Apr 2018 09:25:37 +0000 |
| Subject: | Re: PHP FFI extenesion | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102076@lists.php.net to get a copy of this message | ||
hi Michael,
On Apr 26, 2018 10:31 AM, Michael Wallner <mike@php.net> wrote:
Hey Dmitry!
On 17/04/18 09:29, Dmitry Stogov wrote:
> hi Michael,
>
> it's pitty, I didn't found this extension before.
> thanks for pointing, I'll definetly take a look.
Did you have a chance to look at it yet?
Yeah. I took a look through API and implementation, but didn't try to use it in action.
I exited by the amount of work you did, and see advantages in your approach,
but in general, I like to provide a bit different thing.
Acttually, my FFI extension inspired by LuaJit implementation (copied by Python cffi ABI mode).
I prefer exteremely simple API, simple and compact implementation. I especially, selected run-time
binding, because plan to integrate FFI with JIT (main advantage of LuaJit).
[see below]
> I, also, like the idea of preloading ffi definitions on startup, but I
> would prefer to allow preloading any php files. Especially for FFI, PHP
> wrappers would able to hide dangerous implementation details.
>
I'm not sure the one depends on the other, and how would that be
different to opcache?
With PSI everything related C is encapsulated, you cannot change
anything regarding the access or calling scheme at runtime.
I admit, PSI is far away from being optimized or even finished yet, but
there are a few important key differentiation points:
- the system administrator controls FFI
- parses C headers, no need to duplicate declarations
- function call and data access is pre-defined, not at runtime
Yeah. I see these differences. Reuse of system headers is definitely a big advantage.
Pre-loading and absence of run-time definition, is good from security poin of view, but makes usage
a bit more complex. The thing, I don't like, is a special binding language.
Most probably, both FFI and PSI might be better, taking ideas from the other...
Did you use PSI with some complex libraries?
Thanks. Dmitry.
--
Regards,
Mike
Hey Dmitry!
On 17/04/18 09:29, Dmitry Stogov wrote:
> hi Michael,
>
> it's pitty, I didn't found this extension before.
> thanks for pointing, I'll definetly take a look.
Did you have a chance to look at it yet?
> I, also, like the idea of preloading ffi definitions on startup, but I
> would prefer to allow preloading any php files. Especially for FFI, PHP
> wrappers would able to hide dangerous implementation details.
>
I'm not sure the one depends on the other, and how would that be
different to opcache?
With PSI everything related C is encapsulated, you cannot change
anything regarding the access or calling scheme at runtime.
I admit, PSI is far away from being optimized or even finished yet, but
there are a few important key differentiation points:
- the system administrator controls FFI
- parses C headers, no need to duplicate declarations
- function call and data access is pre-defined, not at runtime
--
Regards,
Mike