Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "Peter H. Coffin" Newsgroups: comp.lang.php Subject: Re: Current PHP implementation Date: Wed, 26 Dec 2012 12:30:40 -0600 Organization: A noiseless patient Spider Lines: 95 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="95eff61b8f8136989e561408eae2762f"; logging-data="31575"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XsI1td1gKKstSZBXk9T7o" User-Agent: slrn/0.9.9p1 (OpenBSD) Cancel-Lock: sha1:n0yfEQLNwhTECEk69i26DH/7pEA= Xref: csiph.com comp.lang.php:7950 On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote: > On 26-12-2012 11:43, Tim Streater wrote: >> In article , Luuk >> wrote: >> >>> On 26-12-2012 03:45, Jerry Stuckle wrote: >>> > On 12/25/2012 8:51 PM, SL@maxis wrote: >>> >> >>> >> I ask this question in 'comp.unix.programmer. It seems like it is more >>> >> related to PHP. >>> >> >>> >> I ask here to find out the current PHP implementation. >>> >> >>> >> Assume at a given time 10 users send in AJAX calls; server end handled >>> >> by '123.php'. >>> >> >>> >> 1. Handler (script): 123.php >>> >> >>> >> Does the server initiate 10 processes to handle the calls ? Which >>> means >>> >> 10 processes are closed after processing !? >>> >> >>> >> 2. Handler (daemon): 123.php >>> >> >>> >> Is the daemon/server creating 10 threads to handle requests ? Which >>> >> means the daemon is always running. Please ignore the memory >>> problem of >>> >> PHP. >> >>> > PHP doesn't handle AJAX calls, nor does PHP start any processes. That >>> > is all done by the web server. You need to be asking in a newsgroup >>> > for the webserver you are using. >> >>> ants fucker >>> >>> What about the answer to this question, >>> >>> (after replacing the 'improper' described handling of PHP) >> >> Anyone understand what Luuk's reply means? >> > > I was asking for the correct answer to OP's question > > The OP seems to want to learn something. > > I think so, because he's asking here, and claims to have done the asking > elsewhere ("I ask this question in ....") > > And the answer is: > "You need to be asking in a newsgroup ...." > > But the name of this newsgroup is NOT alt.where.should.questions.be.asked Fine. I'll do it. It will be correct, within the contexts of PHP. 1. It depends on how the webserver processes things. Typically there will be ten processes spawned. Then processes will exist so long as they have work to do, then exit when they are done or the process timer expires. 2. Daemon version will depend 100% on how you write daemon. Typically, though, PHP is not written with threading in mind. The only mostly-developed process control is essentially a wrapper to fork, works only on unix-like operating systems, and requires PHP to be built as CGI or CLI, not webserver modules. Your daemon may have to spawn a separate process for each connection, as the way to handle multiple connections involves polling sockets to see if any are active and have anything ready for processing, which means any call made that blocks execution to wait for results will hold up processing of all the rest of the sockets, and PHP, not being written for this kind of thing, has a LOT of blocking calls. So, you probably want to spawn a process for every connection, so that none of them are waiting on the others. So, typically, you will have 11 process. Your actual daemon, plus all the subprocesses spawned to handle the work of the connection. You will need to clean these up yourself, either by having each exit as it completes one connection (like the webserver version does) or your daemon controller will have to send the subprocesses signals to exit. Now, was that helpful? Probably not. There's too many things outside PHP managing parts of doing this to describe what's going to happen reliably, and the reason that there's too many things outside of PHP is because PHP's not written with the expectation of doing this in a robust manner, so there's not exactly a big body of work establishing a best-practice. What there is tends to be of the first sort: single-task handlers that are spawned and managed by the webserver in whatever manner the webserver manages the processes. Funny, this is 30 minutes of research, analysis, and typing to come up with what's nothing but a long-winded verson of what Jerry said. You even made me look at a w3sc***ls page to make sure I didn't miss something, and now I feel like I need a shower. -- Whenever you look at a beautiful woman, always remember that somewhere, someone is tired of her.