Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55808
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain phppro.fr from 74.125.82.54 cause and error)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <1318634669.2966.27.camel@guybrush>
Date: Sat, 15 Oct 2011 15:02:38 +0200
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <7E0D65BB-A4EB-4A08-9037-FE3A162E89D7@phppro.fr>
References: <0FE70DAD-7CF9-4EE7-B52D-736CC93876B9@phppro.fr> <1318634669.2966.27.camel@guybrush>
To: =?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Subject: Re: [PHP-DEV] Problem with PHP as a plugin (C++) using embed sapi
From: olivier@phppro.fr (Olivier Hoareau)

Hi Johannes,

Many thanks !

I think SAPI approach is a good one for my purpose, I can then avoid =
using directly the PHP/embed global variables and use functions (i.e. =
the stable api you mention) to manipulate these structures. I need to =
create new SAPI and compile libphp5.so including this SAPI, if I =
understood well.

I read recently about the "load CX before B" solution, but I think it is =
not the way I want to do it (requiring the Loader to know about PHP's =
function =3D> strong coupling) because PHP is only one plugin (I will =
have Python and others as well), and I want a more generic solution.

It is also possible to compile using shared but dynamic linking (and not =
dynamic loading) CX over B (or static), requiring me to provide many B =
versions (I plan to have 5.1 to 5.4 PHP support, if possible, with =
multiple minor versions).

I really like the SAPI approach, and probably give it a try in few days.

Thanks again !

Olivier H.

Le 15 oct. 2011 =E0 01:24, Johannes Schl=FCter a =E9crit :

> Hi,
>=20
> On Fri, 2011-10-14 at 10:49 +0200, Olivier Hoareau wrote:
>> * My use case :
>>=20
>> [A] is a main program written in C++
>> [B] is a C++ "plugin" of [A], compiled in a shared library =
dynamically loaded (dlopen-like functions)
>> [CX] are a libphpX.so C shared libraries compiled with =
"--enable-embed", where "X" is the PHP version number (5.4, 5.3, ..., =
5.0)
>=20
>> Do you have an idea on how to reach my use case ?
>=20
> The simple answer is: You can't do this this way and you have to =
provide
> a [B] for each version of PHP linking [CX].
>=20
> If you really really really want to do this I see two ways, where the
> first is close to what you are doing but still evil:
>=20
> The approach is to add a Loader library which is loaded by [A] and =
then
> first loads [CX] and then the current [B]. This is evil as PHP does =
not
> guarantee API/ABI to stay the same over minor versions. So some random
> function in libphp, which your [B] might be using, can change the
> signature which will easily lead to hard to debug crashes of your
> application.
>=20
> The better approach is to create your own SAPI which exports a for =
your
> purpose stable API which you then can load. Building a SAPI is not
> really hard.
> https://github.com/johannes/pconn-sapi/blob/master/pconnect-sapi.c is
> probably one of the most simple SAPIs, there I'm basically exporting
> three more abstracted functions: pconn_init_php(), =
pconn_shutdown_php()
> and pconn_do_request() which in your case would form your stable API =
for
> your new SAPI. (mind that my pconn_do_request() includes a TSRM
> parameter, in case you don't need threaded execution, can be dropped,
> else you probably have to abstracted it away (make it void* and export
> clean APIs to keep thread context), too)
>=20
> johannes
>=20
>=20