Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102050
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 104.47.34.112 cause and error)
To: =?iso-8859-2?Q?Micha=B3_Brzuchalski?= <michal@brzuchalski.com>
CC: Stanislav Malyshev <smalyshev@gmail.com>, Zeev Suraski <zeev@zend.com>,
	Xinchen Hui <laruence@gmail.com>, Nikita Popov <nikic@php.net>, Bob Weinand
	<bwoebi@php.net>, "Anatol Belski (ab@php.net)" <ab@php.net>, "PHP internals
 list" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] PHP FFI extenesion
Thread-Index: AQHT0yrBnLpXxgz1HEWdw/jxKSLJkaQEFM4AgAB9ZWeAAAGVAIAAAlrlgAAFVQCAABEhCg==
Date: Tue, 17 Apr 2018 08:55:03 +0000
Message-ID: <BN6PR02MB3234A38F7ED99529068D0A56BFB70@BN6PR02MB3234.namprd02.prod.outlook.com>
References: <BN6PR02MB323404E036380FA42924D9A7BFB30@BN6PR02MB3234.namprd02.prod.outlook.com>
 <56794c33-a728-d399-2462-b62ba1b7a509@gmail.com>
 <af4cb226-df79-4b29-810e-52028792c37d@email.android.com>
 <CABdc3WpJhd9csdqtUW4KgRqmiq5vmnbrxEXjskAgPPf96nZk+w@mail.gmail.com>
 <BN6PR02MB323410849DDE3D30E225D2D0BFB70@BN6PR02MB3234.namprd02.prod.outlook.com>,<CABdc3WphObv_YAfpMgKJ9MA-CBSs6F2tN=N5wJEQ-AxEZ3J64A@mail.gmail.com>
In-Reply-To: <CABdc3WphObv_YAfpMgKJ9MA-CBSs6F2tN=N5wJEQ-AxEZ3J64A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BN6PR02MB3234A38F7ED99529068D0A56BFB70BN6PR02MB3234namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0078bd62-1b22-40b5-88a2-08d5a440e8d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2018 08:55:03.3232
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2513
Subject: Re: [PHP-DEV] PHP FFI extenesion
From: dmitry@zend.com (Dmitry Stogov)

--_000_BN6PR02MB3234A38F7ED99529068D0A56BFB70BN6PR02MB3234namp_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Now, I got your idea.

Subclassing CData, and use that types for type hinting may make sense.

I'll put this idea in my TODO, but with low priority.


Thanks. Dmitry.

________________________________
From: Micha=B3 Brzuchalski <michal@brzuchalski.com>
Sent: Tuesday, April 17, 2018 10:51:32 AM
To: Dmitry Stogov
Cc: Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob Weinan=
d; Anatol Belski (ab@php.net); PHP internals list
Subject: Re: [PHP-DEV] PHP FFI extenesion



2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend=
.com>>:

Hi Michal,


I didn't think in this way. I liked to make the simplest API.

I don't expect wide FFI usage in frameworks :)


BTW: I like the idea of use C type names (probably, we may reuse original C=
 type names without additional registration).


currently we can do: $tz =3D $libc->new("struct timezone");

My point was ability to provide an identity to objects wich acts as a struc=
ts. CData class has no idea of what struct type it is and I cannot type hin=
t over that, thats why I thought it would be usefull.
I could then prepare a vendor using pure PHP and wrap everything using type=
s.



I'll think, if we can existend API to use something like: $tz =3D FFI::new(=
$libc->timezone);

At least, this should eliminate C parsing overhead.


Thanks. Dmitry.

________________________________
From: Micha=B3 Brzuchalski <michal@brzuchalski.com<mailto:michal@brzuchalsk=
i.com>>
Sent: Tuesday, April 17, 2018 10:24:02 AM
To: Dmitry Stogov
Cc: Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob Weinan=
d; Anatol Belski (ab@php.net<mailto:ab@php.net>); PHP internals list
Subject: Re: [PHP-DEV] PHP FFI extenesion

Hi Dmitry!

I am not much experienced with C but as a user, I'm just wondering if there=
 is a possibility to extend FFI class and autoregister all or just chosen s=
tructs as classes, for eg.
class Libc extends FFI {
    public function __construct() {
        parent::__construct("...code", "...lib"); // tmp notation
        $this->register('struct timeval', Libc\Timeval::class); // I assume=
 they would extend CData
        $this->register('struct timezone', Libc\Timezone::class); // as abo=
ve
    }
}

So I can instantiate

$tz =3D new Libc\Timezone();
$tv =3D new Libc\Timeval();

and then pass them FFI function

(new Libc())->gettimeofday($tv, $tz);
var_dump($tv-tv_sec, $tv->tv_usec, $tz);

I would be able to prepare than a vendor package with a specified autoloade=
r.
Would that make sense?

Also wouldn't it better if CData class share the same prefixes like FFICdat=
a or FFI\CData?


Cheers,
Michal

2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend=
.com>>:


On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalyshev@gmail.com<mailto:sma=
lyshev@gmail.com>> wrote:
Hi!

> I've spent some time thinking about simple FFI for PHP, and finally, borr=
owed 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 fi=
les 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
smalyshev@gmail.com<mailto:smalyshev@gmail.com>

Hi!

> I've spent some time thinking about simple FFI for PHP, and finally, borr=
owed 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<mailto:smalyshev@gmail.com>



--
regards / pozdrawiam,
--
Micha=B3 Brzuchalski
about.me/brzuchal<http://about.me/brzuchal>
brzuchalski.com<https://brzuchalski.com/>



--
regards / pozdrawiam,
--
Micha=B3 Brzuchalski
about.me/brzuchal<http://about.me/brzuchal>
brzuchalski.com<https://brzuchalski.com/>

--_000_BN6PR02MB3234A38F7ED99529068D0A56BFB70BN6PR02MB3234namp_--