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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov <[email protected]
> <mailto:[email protected]>> 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
>
