Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75118
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.212.176 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <1403882969.12695.97.camel@guybrush>
Date: Fri, 27 Jun 2014 17:48:20 +0200
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C8CD86AB-4118-4546-AF21-B065FBE15FC3@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> <1403878800.12695.58.camel@guybrush> <69DDB98B-1874-43BA-B6DB-B878C8E54DBF@googlemail.com> <1403882969.12695.97.camel@guybrush>
To: =?windows-1252?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Subject: Re: [PHP-DEV] Embedding PHP, few additional questions.
From: ingwie2000@googlemail.com (Ingwie Phoenix)


Am 27.06.2014 um 17:29 schrieb Johannes Schl=FCter =
<johannes@schlueters.de>:

> On Fri, 2014-06-27 at 16:53 +0200, Ingwie Phoenix wrote:
>>>=20
>>> 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.
>> What do you mean by that? It might be my english, but I did not very
>> much understand what you ment.
>>=20
>=20
> You are asking "How can I use opcache in some environment, which I
> actually don't know"  while the actual question should be "What's =
PHP's
> internal architecture especially in regards to SAPIs". Opcache fits =
in,
> in the end, once the architecture is understood.
Okay. I will be looking into the source of PHP and documentation, going =
to try and understand it further. Looks like, that what I have learned =
so far, is like just 1% of what I really need to know - kinda scary, but =
also a challenge I wish to take on.

>> But now, you actually finally helped me understand soemthing that I
>> always wondered: the TSRM_xx macros! Now it makes sense why they are
>> everywhere, acting as a sort-of mutex=85or more, a thing to
>> differenciate between threads. Always got confused about how this
>> actually is used - well, now I know. A lesson a day, keeps the
>> dumbness away, methinks! ^.^
>=20
> "thread safe resource manager" ... again try to dive in, into the
> architecture of PHP.
Well, I tried to understand all the odd TSRM macros before, but I =
couldnt find a real answer - just that I had to put them into certain =
places, but never why. Now it just clicks in and makes sense. Sadly, =
some parts of PHP are not documented - or, the documentation is very =
outdated=85 (I.e. I found an embedding guide for PHP 4 before finally =
finding one for 5.)

>=20
>> Oh s=85 That I did not know/consider. So if, for some reason, the PHP
>> instance crashes or dies, all other instances, and possibly the rest
>> of the application, dies too? Wow. Guess I should create a watchdog
>> that keeps track of the service.
>=20
> Well each service should be watched. On good operating systems (note:
> Solaris ad coming up) you can define contracts in regards to processes
> the kernel should watch as soon as they misbehave a service manager =
will
> be notified and can take action. But well, that's a generic issue, =
also
> nodejs/v8 can crash in some situations etc.
> For a system design the question is: How can you limit the risk and
> impact. With your design everything is lost and has to be restarted.
Now that you notified me of this thing that I did not think about, I =
will have to really make a new design. I have not used Solaris, but I =
heared many good things. Currently I have stuck to Debian - but this =
enhancement sounds like one point to consider switching distros. I am =
getting a new server anyway, good opportunity to learn new things. o.o

>> The goal is to run websockets, a cdn and db cache together with
>> HTTP(S). So turning into REST based service would actually make the
>> structure more complex.
>=20
> You seem to have a different definition of "complex" than me. I =
consider
> a monolithic block, mixing multiple language runtimes which follow
> completely different paradigms ("stay away from threads an use events
> and be light weight" vs. "have a shared nothing conatainer handling =
one
> request after another") and which both are quite sophisticated to be
> quite complex, whereas I consider an architecture of smaller =
independent
> components, which I can maintain, scale, ... independently cleaner.
>=20
> johannes

It=92s definitively not the first time somebody said that=85haha. I know =
that PHP and NodeJS have by -far- different ideas of how things should =
be handled and worked. But currently available webservers dont support =
Websockets too well. So my last solution was to use nodejs directly. And =
since I am often on environments where ports other than 80 are blocked =
(my school, for example). So I was looking for a way to use it all thru =
one port, and many things behind the scenes. Which in the end made me =
end up with getting to the point, where I needed to run PHP underneath =
nodejs. Its not truely a =84language-to-language=93 binding - its just =
giving PHP something to process and return the output. The both are =
completely isolated - except the fact that they are stuck in the same =
memory/program space - and dont really interact with each other. =
Basically, I just want to write a SAPI under nodejs, simialr to Apache. =
And that is why I am currently sitting here, with mod_php5.c open.

Kind regards, Ingwie.=