On Fri, 2015-01-23 at 07:38 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:
> > Am 20.01.2015 um 23:11 schrieb Johannes Schlüter <johan...@schlueters.de>:
> >
> > Hi,
> >
> > On Tue, 2015-01-20 at 06:36 +0100, Kevin Ingwersen (Ingwie Phoenix)
> > wrote:
> >> Today I have started to concept a new SAPI which I have wanted to do
> >> in quite a while now. To learn more, here is a README:
> >> https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md
> >> <https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md>
> >
> > I have to agree with Bas van Beek that I don't see the benefit of using
> > a custom protocol over existing ones. This protocol doesn't seem to have
> > less overhead than HTTP and you loose ability of using established
> > libraries, debugging tools, scaling tools, ...
> …but you gain the headache of FastCGI. I just wasted 3 hours, trying
> to get this working right. It was more of an issue with the script
> language I am using to write the web server - but getting my head
> around FastCGI in the first place is a mess. When was it written and
> published, 1996?
Written and published in 1996 means there are stable tools and
libraries ;-)
And well, a few hours learning FastCGI vs. long time to invent something
new. But your call, and maybe you are successful and create something
better ...
> > Using threads means pain with PHP. One thing is TSRM (while
> > replaced in PHP 7 with TLS)[...]
> I thought TSRM was stable?
TSRM itself is stable. Doesn't mean it's good. It has a notable
performance penalty (Zend/bench.php on my machine with 5.6 is ca. 2.0s
vs 2.6s, also requires more memory, this is better in PHP 7, but not
perfect either) and is less tested (I doubt we have many devs actually
running in a threaded context to observe races, true, it's some time
since I debugged such a thing but don't know how many of our "can't
reproduce" bugs are threading issues ...)
> > [...]the other thing is stability: A crash in one
> > thread will crash the whole server, in a process-based model like
> > FastCGI or apache mod_prefork only the single process and request will
> > die. Crashing PHP is trivial (infinite recursion etc.)
> My idea was to use a thread per process watchdog. So a request is
> started, and it is given to a new thread - so it has its own PHP
> process running and when that one dies, it can send back an error
> message accordingly. PHP was not ment to run in the same process in
> the first place.
If PHP crashes due to something like
$ php -nr 'function a() { call_user_func("a"); } a();'
Segmentation fault (core dumped)
your watchdog thread will die, too, as will each other PHP thread in the
same process. (yes, eventually one could catch SIGSEGV and then try to
do some magic but welcome to devil's kitchen)
> pcntl_fork() is not in the standart PHP it seems, otherwise I would
> have written JRP using that. But since this is going to be a
> general-purpose SAPI anyway, I can just write it in C++ from the
> get-go.
pcntl_fork is a default extension for CLI SAPI, for other SAPIs it's
disabled. Distributors sometimes split that up differently. Properly
forking however is complicated when having opened resources. Also this
sounds like long running scripts ... since 5.3's GC it's better, but
PHP's memory and resource handling isn't really aimed at scripts running
longer than a few milliseconds.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
