Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55807
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Olivier Hoareau <olivier@phppro.fr>
Cc: internals@lists.php.net
In-Reply-To: <0FE70DAD-7CF9-4EE7-B52D-736CC93876B9@phppro.fr>
References: <0FE70DAD-7CF9-4EE7-B52D-736CC93876B9@phppro.fr>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 15 Oct 2011 01:24:29 +0200
Message-ID: <1318634669.2966.27.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Problem with PHP as a plugin (C++) using embed sapi
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Fri, 2011-10-14 at 10:49 +0200, Olivier Hoareau wrote:
> * My use case :
> 
> [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)

> Do you have an idea on how to reach my use case ?

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].

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:

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.

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)

johannes