On 1/31/19 7:23 PM, Joe Watkins wrote: > Hi Zeev, Dmitry, > > It is not my only concern, I'm grateful for the clarification whatever. > > These are your actual words from the RFC: > > > This works, but this functionality is not supported on all libffi > platforms, it is not efficient and leaks resources by the end of > request. It's recommended to minimize the usage of PHP callbacks.
Do you understand what is PHP callback in context of FFI? In the following example, it's used to override zend_write by PHP function, but FFI can't know when this callback is not used by C anymore, and keeps it until the end of request. <?php $zend = FFI::cdef(" typedef int (*zend_write_func_t)(const char *str, size_t str_length); extern zend_write_func_t zend_write; "); $orig_zend_write = clone $zend->zend_write; $zend->zend_write = function($str, $len) { global $orig_zend_write; $orig_zend_write("{\n\t", 3); $ret = $orig_zend_write($str, $len); $orig_zend_write("}\n", 2); return $ret; }; echo "Hello World!\n"; $zend->zend_write = $orig_zend_write; ?> > To me, a foreign function interface where one side of the interface > sounds broken and inefficient, according to the author, is scary. I've > never worked with libffi, so don't know if that's normal ... but I think > you can understand my thoughts here. There is the same issue with FFI for LuaJIT. I'm not sure if Python CFFI supports callbacks. > Aside from whatever technical issues I may have misinterpreted or > misidentified, these are not my main objections to it being merged. I got it. Thanks. Dmitry. > > Cheers > Joe > > On Thu, 31 Jan 2019 at 17:20, Zeev Suraski <z...@php.net > <mailto:z...@php.net>> wrote: > > > > On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov <dmi...@zend.com > <mailto:dmi...@zend.com>> wrote: > > The fact that FFI may leak, is because it uses "unmanaged > memory" (like > in real C). PHP reference counting and GC just can't handle all the > cases. It's impossible to automatically know what to do with C > pointer, > when we get it from function or another structure. In this case > programmer have to care about freeing the pointer themselves > (like in C). > > This obviously doesn't count as 'leaks'. If it did, we could say > that the Zend Extension API leaks, as it's completely up to the > developer to handle memory management. > > Joe - if that's your concern, I think it's fair to say it's > invalid and you have nothing to worry about. > > Zeev >