Re: Embedding PHP, few additional questions.

Am 27.06.2014 um 11:18 schrieb Johannes Schlüter <johannes@schlueters.de>: > 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. Ohh. So the interpreter needs to stay „online“ in order to also keep the cache up. Thanks, that made things clearer for me. :) >> 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 … So there is two methods of supplying headers? O.o oha. Well I will go and check the files out and see what it helps me. > >> 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 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. 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. Kind regards, Ingwie.