Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102049 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1854 invoked from network); 17 Apr 2018 07:51:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Apr 2018 07:51:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=michal@brzuchalski.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=michal@brzuchalski.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain brzuchalski.com from 188.165.245.118 cause and error) X-PHP-List-Original-Sender: michal@brzuchalski.com X-Host-Fingerprint: 188.165.245.118 ns220893.ip-188-165-245.eu Received: from [188.165.245.118] ([188.165.245.118:56552] helo=poczta.brzuchalski.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C4/79-36099-F87A5DA5 for ; Tue, 17 Apr 2018 03:51:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by poczta.brzuchalski.com (Postfix) with ESMTP id 1C1F72984233 for ; Tue, 17 Apr 2018 09:51:41 +0200 (CEST) Received: from poczta.brzuchalski.com ([127.0.0.1]) by localhost (poczta.brzuchalski.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNokMxnCuoeY for ; Tue, 17 Apr 2018 09:51:38 +0200 (CEST) Received: from mail-ot0-f181.google.com (unknown [74.125.82.181]) by poczta.brzuchalski.com (Postfix) with ESMTPSA id C18562984239 for ; Tue, 17 Apr 2018 09:51:33 +0200 (CEST) Received: by mail-ot0-f181.google.com with SMTP id d9-v6so20392293oth.10 for ; Tue, 17 Apr 2018 00:51:33 -0700 (PDT) X-Gm-Message-State: ALQs6tDo7WcXNPO2KA1Fi9vIv0Aw0CuVUCKSNn3LbvLG2o3Ote66lPdv AxG4P6XSjjGtDFHxK90yb1DoMoLIB3gP0TfiDfc= X-Google-Smtp-Source: AIpwx4/uwasDC55LgNduAd8cp5n/+M+z+1N/Sd5VFm5ijPD3UVE1Xb7KXE9ihwFrona0G5FVdK0nOEZ1tEslrU5Spy8= X-Received: by 2002:a9d:4794:: with SMTP id b20-v6mr547042otf.183.1523951492740; Tue, 17 Apr 2018 00:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:7106:0:0:0:0:0 with HTTP; Tue, 17 Apr 2018 00:51:32 -0700 (PDT) In-Reply-To: References: <56794c33-a728-d399-2462-b62ba1b7a509@gmail.com> Date: Tue, 17 Apr 2018 09:51:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Dmitry Stogov Cc: Stanislav Malyshev , Zeev Suraski , Xinchen Hui , Nikita Popov , Bob Weinand , "Anatol Belski (ab@php.net)" , PHP internals list Content-Type: multipart/alternative; boundary="000000000000613e9d056a069b96" Subject: Re: [PHP-DEV] PHP FFI extenesion From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --000000000000613e9d056a069b96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-17 9:46 GMT+02:00 Dmitry Stogov : > 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 structs. CData class has no idea of what struct type it is and I cannot type hint over that, thats why I thought it would be usefull. I could then prepare a vendor using pure PHP and wrap everything using types. > > 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=C5=82 Brzuchalski > *Sent:* Tuesday, April 17, 2018 10:24:02 AM > *To:* Dmitry Stogov > *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob > Weinand; Anatol Belski (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 structs 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 > above > } > } > > 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 > autoloader. > Would that make sense? > > Also wouldn't it better if CData class share the same prefixes like > FFICdata or FFI\CData? > > > Cheers, > Michal > > 2018-04-17 9:18 GMT+02:00 Dmitry Stogov : > > > > On Apr 17, 2018 2:49 AM, Stanislav Malyshev 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 an= d > 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 we= b > 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 > smalyshev@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 an= d > 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 > > > > > -- > regards / pozdrawiam, > -- > Micha=C5=82 Brzuchalski > about.me/brzuchal > brzuchalski.com > --=20 regards / pozdrawiam, -- Micha=C5=82 Brzuchalski about.me/brzuchal brzuchalski.com --000000000000613e9d056a069b96--