Re: Embedding PHP, few additional questions.

On Fri, 2014-06-27 at 14:55 +0200, Ingwie Phoenix wrote: > So there is two methods of supplying headers? O.o oha. Well I will go there are request and response headers and then there are different situations the response headers might be set in ... > and check the files out and see what it helps me. Yes, looking at the code is useful to understand it. > 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. 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. > 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. As said before the request context is defined by request startup and shutdown functions. This works by using globals to keep the state. In threaded environments, to run multiple requests in parallel we have TSRM as thread isolation layer binding a request context to a thread. Thus the request is bound to a thread. Once it's finished it can handle the next request. My pconn SAPI supports some form of parallelism, too. check the main.c file. But for your project this becomes really messy - a "request" comes in, you start a worker thread fill it with the data. The output hooks then have to be written in a way to capture the output and send it back to the v8 thread which will, once it has time handle those and report back to the javascript code. Now if you want to make it efficient you can't create a fresh thread each time but instead want to create a worker pool of threads and some scheduler putting tasks in. Then besides that complexity you have to mind other issues in this setup. for instance TSRM mode is slower than non TSRM mode. Or as everthing is one process. A crashing PHP (stack overflow due to infinite recursion) will kill all parallel PHP requests and the whole node instance. So really if you plan on operating such a thing write a FastCGI or FPM module calling PHP in such a way. Or even better: Make your PHP code a web service (REST etc.) so both sides can be scaled individually. If you want to do this for academic purposes or proving me wrong, please read the code and try to understand it. Experiment with it in small pieces etc. johannes