On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: 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. Agree. - 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. I have a bit opposit idea. We will keep FFI for CLI but disable it for web apps (like dl()). At the same time, we will develop a technology to preload and reuse PHP files across requests. And allow FFI there. - 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 Yeah. Like this. - 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). Programming using FFI, is very similar to C. I'm not sure, if we may provide good debugging facilities. Thanks for review. Dmitry. -- Stas Malyshev smalys...@gmail.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. > 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 smalys...@gmail.com
