Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75111
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: <0DF815F8-5991-46EC-9BD4-53575F774BAC@googlemail.com>
References: <A4851D00-E21D-4A74-8A84-C77B4DE09FAD@googlemail.com>
	 <1403777679.12695.14.camel@guybrush>
	 <0DF815F8-5991-46EC-9BD4-53575F774BAC@googlemail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 27 Jun 2014 11:18:36 +0200
Message-ID: <1403860716.12695.34.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 07:57 +0200, Ingwie Phoenix wrote:
> I also did some research, and learned that OPCaches are stored in
> shared memory. Wouldn’t shared memory get lost when the interpreter is
> shut down, or how is this working? Is shared memory actually „fully
> associated“ to a program? Excuse me for the dumb question, It is just
> my first direct confrontation with shared memory, ever.

In general "shared memory" might mean many things. In this opcache case
you can assume that when PHP is shutdown (not only the request) the
shared memory is freed.

> In your pconn SAPI, you are telling PHP that you are not going to use
> headers… but, in my case, I have an incomming HTTP request and should
> very much forward those headers. What is the function that I must look
> at, to copy my headers?

php-src/sapi/ has quite a few examples and php-src/main/SAPI.c and
related files show implementation of details. If you're referring to the
no_headers flag this is about setting headers from PHP which would
otherwise be sent to the SAPI's header hooks ...

> As this is going to be a nodejs module (v8php), I will link most of
> these functions into JS scope by supplying wrappers and the like.
> Going to be pretty interesting to see this in actual work, and
> comparign the speed to just using child_process.spawn.

It will be worse - without really looking into child_process.spawn I
assume that is non-blocking. I assume you're PHP implementation will be
blocking and therefore hold all other things in nodejs. For making it
non-blocking you'd have to play a bit with threads and send PHP of to
worker threads and ensure it's compiled in TSRM mode which costs extra
time while executing. The better approach would be to use FastCGI / FPM
as communication with PHP. While I'd question the architecture of such
an system ...

johannes