> 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?

> Anyways:
> 
>> But in order for me to work this out as good as I can - especially the
>> PHP API at the bottom - I need to know just a thing I could not find
>> within the public PHP headers: When I have an Array, now can I turn
>> that into an object?
> 
> What does that mean? Object in PHP-sense or in C-sense or C++-sense or
> JSON? They are all different things.
Oh damn. I should ahve been more clear there. I was reffering to a PHP object.

> PHP arrays essentially are a zval with a HashTable, which can be used
> via zend_hash.h API, there also exist some array_* shortcuts in
> zend_API.h, this changes a bit between PHP 5 and 7 so you should pick
> the version.
> 
> If you want a PHP object you use the object APIs, I tend take ideas from
> the reflection's implementation as it does most object things.
> 
> If you want the equivalent of  $obj = (object)$array; I question whether
> that makes sense (you want to write json output in the end, no? so why
> do an relative expensive transformation instead of directly creating
> json?) but convert_to_object() in zend_operators.c is your friend.
> 
> You want to create a JSON object? Look at the json extension, which
> doesn't have an API but is trivial to copy. (mind the license of the
> utf8 decoder, if needed)
> 
> Unless you have precise questions it's hard to answer expect pointing
> out default resources (PHP source, Sara's book,
> phpinternalsbook.com, …)
Since there is no „object syntax“ in PHP as there is in JavaScript for 
instance, I can’t pass an actual object and need to hack my way around and use 
an associative array instead. Because there is a difference in doing

$obj = new stdClasS;
$obj->propA=…;
$obj->propB=…;
func($obj);

And

func([propA=>..., propB=>...]); // my Mail program mis-fixes quotes, so I left 
them out

And in the end, all I need is to iterate over each key - at which I realized, I 
dont even need to convert it into an Object at all and can use the existing 
HashTable API… My failure on that.

>> I’d be happy to hear what you think of this concept as well. As
>> mentioned in the README, process on this will begin later. For now, I
>> am going to use helper libraries, but late ron I want to strip the
>> project to lesser and lesser dependencies. But it will remain being
>> written in C++.
> 
> One thing I noticed is that you have a dependency on some thread
> libraries (while I wonder why C++08 libraries instead of C++11's thread
> support).
Mostly because the C++11 support across compilers is very wobbly. TinyThread++ 
has the C++11 API mirrored, so it can be replaced by the STL threads on a newer 
compiler. But for anything that doesnt support the C++11 threads correctly, 
this library can do.

> Using  threads means pain with PHP. One thing is TSRM (while
> replaced in PHP 7 with TLS)[...]
I thought TSRM was stable?

> [...]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.

> I also see PHP-CPP in your dependencies, that is nice but for writing
> extensions, not SAPIs. And last time it checked it didn't really do good
> under TSRM (haven't checked for some time)
It is fine with TSRM, actually. I only want to use it to simplify the built-in 
extension that allows custom messages to be sent back to the client (the 
instance that issued the request).

> My example I use to answer SAPI questions is
> https://github.com/johannes/pconn-sapi which is probably the most simple
> SAPI available, working both in threaded and non-threaded mode.
Where else do you think I am getting all the SAPI docs I need in a cheat-sheet 
form? :)

To clarify: I mainly want to replace FastCGI. Its a pain to work with and I am 
spending more time on getting a proper FastCGI connection going than writing on 
my site. There is a good reason that programs like NodeJS allow webservers to 
be scripted; t make things very custom and dynamic. But since PHP’s only output 
seems to be FastCGI, the CLI - which doesn’t, obviously, support the header 
stuff - or probably something i have overlooked, I will need to write my own…

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.

Kind regards, Ingwie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to