Hi,
I've spent some time thinking about simple FFI for PHP, and finally, borrowed most ideas from LuaJIT.
This is an initial PoC. It was tested on Linux only.
https://github.com/dstogov/php-ffi
I would appreciate review, comments and ideas about missing features and functionality.
Thanks. Dmitry.
2018-04-13 16:27 GMT+03:00 Dmitry Stogov dmitry@zend.com:
Hi,
I've spent some time thinking about simple FFI for PHP, and finally,
borrowed most ideas from LuaJIT.This is an initial PoC. It was tested on Linux only.
https://github.com/dstogov/php-ffi
I would appreciate review, comments and ideas about missing features and
functionality.Thanks. Dmitry.
Hello Dmitry,
PECL has an extension like that listed, although it's old and probably does
not work, https://pecl.php.net/package/ffi so it might need replacing to
avoid confusion.
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
I've spent some time thinking about simple FFI for PHP, and finally, borrowed most ideas from LuaJIT.
This is an initial PoC. It was tested on Linux only.https://github.com/dstogov/php-ffi
I would appreciate review, comments and ideas about missing features and functionality.
A better FFI is sorely needed so thanks for looking into this.
I don't particularly like having to manually specify the definitions.
IIRC if the DSO has debugging symbols libffi can provide them but
honestly I haven't looked at libffi in years so I might be
mis-remembering.
Hi!
I've spent some time thinking about simple FFI for PHP, and finally, borrowed most ideas from LuaJIT.
This is an initial PoC. It was tested on Linux only.
https://github.com/dstogov/php-ffi
I would appreciate review, comments and ideas about missing features and functionality.
Looks interesting. On a cursory look, couple of thoughts:
- I think all the classes involved should be made non-serializable and
non-unserializable. - Does it load shared libraries, or only uses ones already loaded? If
the former, I think there should be a way to unload them at the request
end (even though it might be performance issue, and may be not possible
if persistent resources are involved), otherwise we leak state between
requests. - OTOH, people may want to load a set of persistent definitions from a
config file, etc. - the ffi definition probably won't change much, and
having locked down set of FFI interfaces the rest of the code is using
might be beneficial - Since this thing is dealing with raw pointers, etc., from PHP code,
there may be a lot of crashes from using this extension in a wrong way.
I wonder which facilities we could provide for helping people to debug
it (for people who aren't super-comfortable using gdb on PHP engine).
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Nice that FFI is of interest again, so may I kindly point you to ext-psi?
https://github.com/m6w6/ext-psi
It follows a different approach, though, that it requires definition
files on startup, not at runtime.
Basically:
$ cat >time.psi <<EOF
#include <time.h>
/* time_t time(time_t *tloc); man 2 time */
function psi\time() : int {
let tloc = NULL;
return time(tloc) as to_int(time);
}
EOF
$ ./sapi/cli/php -d psi.directory=. -r 'var_dump(psi\time());'
It stalled the last months because I have been fighting health issues
since last summer, but I did post a link to internals about a year ago:
https://externals.io/message/98212#98259
--
Regards,
Mike