Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75114
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Ingwie Phoenix <ingwie2000@googlemail.com>
Cc: internals@lists.php.net
In-Reply-To: <02B340AD-6EED-497D-85EC-F5C37A7504B6@googlemail.com>
References: <A4851D00-E21D-4A74-8A84-C77B4DE09FAD@googlemail.com>
	 <1403777679.12695.14.camel@guybrush>
	 <0DF815F8-5991-46EC-9BD4-53575F774BAC@googlemail.com>
	 <1403860716.12695.34.camel@guybrush>
	 <02B340AD-6EED-497D-85EC-F5C37A7504B6@googlemail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 27 Jun 2014 16:20:00 +0200
Message-ID: <1403878800.12695.58.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Embedding PHP, few additional questions.
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2014-06-27 at 14:55 +0200, Ingwie Phoenix wrote:
> So there is two methods of supplying headers? O.o oha. Well I will go

there are request and response headers and then there are different
situations the response headers might be set in ...

>  and check the files out and see what it helps me.

Yes, looking at the code is useful to understand it.

> Yes. child_process.spawn is non-blocking - it just returns an Event
> Emitter and the stdin/stdout/stderr stream resources respectively. In
> fact, I want to model my PHP binding in such fashion too. Currently, I
> am firstly wanting to understand the API and create a good base for
> the module. Then extend it to be async/non-blocking. So, I will be
> replacing output and error output functions with respective callbacks.
> However, I am not planning to add any functionality to create userland
> functions from JS. I only want to be able to prepare a bunch of
> information - the file to be executed, the in-/output methods, etc -
> then give it to a function, which will create a new thread (in libuv,
> uv_async_t, or soemthing) and execute the given PHP file with the
> engine. The handle returned will contain the running PHP instance - or
> at least, i need to find a way to run PHP and then keep it up, so that
> my OPCaches wouldnt get lost.

Forget Opcache. Get the PHP model of the request based approach which
goes through PHP's complete architecture. opcache comes in in the end
(more or less) easily.

> But this brings me to another question.
> 
> When I look into pconnect SAPI, I can see that you start PHP…but
> actually, I can see no real reference to a „PHP interpreter object“.
> In a third-party implementation of PHP, called PH7, one has to create
> a ph7_engine_t first - which corresponds to the actual engine
> instance.
> 
> If I want to keep PHP running - and even multiple instances - how
> would I do that? If I have no handle to differenciate between PHP
> instances, then I have a small problem…and I would have to actually
> fall back to using PHP-CGI/-FPM, which I wanted to avoid, as I was
> hoping for a speed improvement if everything happened in-process/per
> thread.

As said before the request context is defined by request startup and
shutdown functions. This works by using globals to keep the state. In
threaded environments, to run multiple requests in parallel we have TSRM
as thread isolation layer binding a request context to a thread. Thus
the request is bound to a thread. Once it's finished it can handle the
next request.
My pconn SAPI supports some form of parallelism, too. check the main.c
file.

But for your project this becomes really messy - a "request" comes in,
you start a worker thread fill it with the data. The output hooks then
have to be written in a way to capture the output and send it back to
the v8 thread which will, once it has time handle those and report back
to the javascript code. Now if you want to make it efficient you can't
create a fresh thread each time but instead want to create a worker pool
of threads and some scheduler putting tasks in.

Then besides that complexity you have to mind other issues in this
setup. for instance TSRM mode is slower than non TSRM mode. Or as
everthing is one process. A crashing PHP (stack overflow due to infinite
recursion) will kill all parallel PHP requests and the whole node
instance.

So really if you plan on operating such a thing write a FastCGI or FPM
module calling PHP in such a way. Or even better: Make your PHP code a
web service (REST etc.) so both sides can be scaled individually.

If you want to do this for academic purposes or proving me wrong, please
read the code and try to understand it. Experiment with it in small
pieces etc.

johannes