Re: PHP FFI extenesion

From: 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

« previous php.internals (#102076) next »