Re: Embedding PHP, few additional questions.

Am 27.06.2014 um 16:20 schrieb Johannes Schlüter <johannes@schlueters.de>: > 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 … Whoah, so many options... o-o >> 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. What do you mean by that? It might be my english, but I did not very much understand what you ment. >> 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. Actually, I am indeed scrolling thru pconn. It currently has the most clean API showcase that I can see, to be very honest. 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…or 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! ^.^ > 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. Oh s… 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. > 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. 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. Actually, I can show you the concept documentation. It is still in progress, but it lists quite a lot of the concepts, ideas and things I will/want to do. Maybe it helps why I am even doing this. [1] > 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 I am reading all the code that I can now, that is related to what I am doing. I just noticed that the PHP on OS X has no maintainer-zts. So, I am compiling 5.5.14 with embed and maintainer-zts meanwhile… Thanks for all your help, it really brings me forward a lot! Kind regards, Ingwie. [1]: https://gist.github.com/IngwiePhoenix/e32757a2983213fcc050 [2]: https://github.com/IngwiePhoenix/v8php The repo where I will put my stuff…very rough layout, not usable. Just there to be there.