Re: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
On Thu, 9 Jul 2020 at 09:01, Dan Ackroyd wrote: > > On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов wrote: > > > > I would like to start discussion about the «FFI Improvements» RFC. At the > > moment, I do not have the right to create wiki page, so I post it on the > > github: > > https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md > > > > For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible. > It would be really good if someone involved in getting FFI into core > could comment if there was any specific reason for not doing that > already. It's too late for PHP 8.0 but it would still be good to hear from anyone who knows about the choices made for FFI, so that it can be improved. Otherwise should we start considering whether the FFI stuff is an experiment that is not being supported? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re[2]: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
> One other thing that probably also should be addressed is the
> behaviour around closures that was noted in the RFC
> https://wiki.php.net/rfc/ffi#php_callbacks :
During work with FFI, I did not encounter problems associated with this. There
are more significant ones, for example, the lack of a cast of types in
structures:
$struct = FFI::cdef(‘struct Test { char* string_field; }’)->new(‘Test’);
$struct->string_field = «string»; // Error
However, these internal problems including a memory leak when working with
anonymous functions, I found it unnecessary in this RFC. Maybe a little later.
> So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
> name that is somewhat meaningful.
I'm afraid in this case, developers will use an easier to use feature. And this
means that just so we can’t deprecate it later.
However, if this argument is not very convincing, then as the name of the new
function, I would suggest «FFI::fromSource(...)».
>Четверг, 9 июля 2020, 11:01 +03:00 от Dan Ackroyd :
>
>On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов < n...@xakep.ru > wrote:
>>
>> I would like to start discussion about the «FFI Improvements» RFC. At the
>> moment, I do not have the right to create wiki page, so I post it on the
>> github:
>> https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
>>
>
>Thanks for starting this discussion. I think FFI definitely needs to
>be improved before it will see widespread adoption.
>
>> Please note that for backward compatibility, allow option with
>> passing a string as the second argument to the FFI::cdef() method.
>
>Rather than changing the function signature of FFI::cdef, I think it
>would be better to introduce a new function, and then at some point
>deprecate and remove the old one (if anyone cares to).
>
>So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
>name that is somewhat meaningful.
>
>For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
>It would be really good if someone involved in getting FFI into core
>could comment if there was any specific reason for not doing that
>already.
>
>One other thing that probably also should be addressed is the
>behaviour around closures that was noted in the RFC
>https://wiki.php.net/rfc/ffi#php_callbacks :
>
>> It's possible to assign PHP closure to native variable of
>> function pointer type (or pass it as a function argument).
>> 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.
>
>I really don't know what can or should be done for that, but having a
>feature that can't be used safely seems like a bad feature.
>
>cheers
>Dan
>Ack
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php
>
--
Kirill Nesmeyanov
Re: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов wrote: > > I would like to start discussion about the «FFI Improvements» RFC. At the > moment, I do not have the right to create wiki page, so I post it on the > github: > https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md > Thanks for starting this discussion. I think FFI definitely needs to be improved before it will see widespread adoption. > Please note that for backward compatibility, allow option with > passing a string as the second argument to the FFI::cdef() method. Rather than changing the function signature of FFI::cdef, I think it would be better to introduce a new function, and then at some point deprecate and remove the old one (if anyone cares to). So rather than FFI::cdef() it could be FFI::ghij() or maybe even a name that is somewhat meaningful. For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible. It would be really good if someone involved in getting FFI into core could comment if there was any specific reason for not doing that already. One other thing that probably also should be addressed is the behaviour around closures that was noted in the RFC https://wiki.php.net/rfc/ffi#php_callbacks: > It's possible to assign PHP closure to native variable of > function pointer type (or pass it as a function argument). > 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. I really don't know what can or should be done for that, but having a feature that can't be used safely seems like a bad feature. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
Hi all! I would like to start discussion about the «FFI Improvements» RFC. At the moment, I do not have the right to create wiki page, so I post it on the github: https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md The proposal: - Contains improvements regarding the harmonization of supported FFI directives («define FFI_XXX») in different operating modes (cdef and load). - And he suggests solving the problem of the inability to work with some types of libraries that contain loading of other libraries. In addition, I want to add that I am not a C developer, and I understand that this reduces the chances of adopting this RFC. However, I think that the proposal is useful and if approved, someone will help to implement it.
