FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Current PHP implementation
Show: Today's Messages :: Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
Current PHP implementation [message #180005] Wed, 26 December 2012 01:51 Go to next message
SL@maxis is currently offline  SL@maxis
Messages: 2
Registered: December 2012
Karma: 0
Junior Member
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.


Thanks for any info. Happy Boxing day.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Current PHP implementation [message #180007 is a reply to message #180005] Wed, 26 December 2012 02:45 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
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.
>
>
> Thanks for any info. Happy Boxing day.
>

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Current PHP implementation [message #180009 is a reply to message #180007] Wed, 26 December 2012 10:26 Go to previous messageGo to next message
Luuk is currently offline  Luuk
Messages: 329
Registered: September 2010
Karma: 0
Senior Member
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.
>>
>>
>> Thanks for any info. Happy Boxing day.
>>
>
> 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)

?
Re: Current PHP implementation [message #180010 is a reply to message #180009] Wed, 26 December 2012 10:43 Go to previous messageGo to next message
Tim Streater is currently offline  Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
Senior Member
In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
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?

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
Re: Current PHP implementation [message #180011 is a reply to message #180010] Wed, 26 December 2012 12:15 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
Senior Member
On 26/12/12 10:43, Tim Streater wrote:
> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
> 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 think he means incorrect. I.e. the contention that PHP dosnt...its all
done by the server..


...and the definition of a server to be a box that serves, which
obviously contains the PHP.


--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
Re: Current PHP implementation [message #180012 is a reply to message #180005] Wed, 26 December 2012 12:40 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
SL@maxis wrote:
^^^^^^^^
Who?

> I ask this question in 'comp.unix.programmer. It seems like it is more
> related to PHP.

It is not more related to PHP as apples are to oranges.

> I ask here to find out the current PHP implementation.

Do you know what PHP is?

> Assume at a given time 10 users send in AJAX calls; server end handled by
> '123.php'.

| AJAX call \noun\
| Term indicating that the per-
| son using it has no clue what
| they are talking about. See
| also: AJAX.

> 1. Handler (script): 123.php
>
> Does the server initiate 10 processes to handle the calls ? Which means 10
> processes are closed after processing !?

Server processes are not the domain of the compiler-interpreter of a
programming language, but of the Web server software.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
Re: Current PHP implementation [message #180013 is a reply to message #180007] Wed, 26 December 2012 13:45 Go to previous messageGo to next message
Denis McMahon is currently offline  Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
Senior Member
On Tue, 25 Dec 2012 21:45:58 -0500, Jerry Stuckle wrote:

> PHP doesn't handle AJAX calls

If the client calls a php script using the client side ajax mechanism,
then the php script handles the ajax call.

However, what part of the client generates the call is irrelevant to the
php. All that the php script "knows" is that it has been invoked in an
environment that may include several predefined arrays. It has no idea
whether it was invoked from a link click, a form submission, an embedded
object or an ajax call, although it may be able to determine this from
its data environment.

--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
Re: Current PHP implementation [message #180014 is a reply to message #180010] Wed, 26 December 2012 13:55 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 12/26/2012 5:43 AM, Tim Streater wrote:
> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
> 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?
>

He has no idea what he's talking about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Current PHP implementation [message #180016 is a reply to message #180010] Wed, 26 December 2012 16:12 Go to previous messageGo to next message
Luuk is currently offline  Luuk
Messages: 329
Registered: September 2010
Karma: 0
Senior Member
On 26-12-2012 11:43, Tim Streater wrote:
> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
> 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
Re: Current PHP implementation [message #180018 is a reply to message #180016] Wed, 26 December 2012 18:30 Go to previous messageGo to next message
Peter H. Coffin is currently offline  Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
Senior Member
On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote:
> On 26-12-2012 11:43, Tim Streater wrote:
>> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
>> 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.
Re: Current PHP implementation [message #180020 is a reply to message #180018] Wed, 26 December 2012 19:51 Go to previous messageGo to next message
Luuk is currently offline  Luuk
Messages: 329
Registered: September 2010
Karma: 0
Senior Member
On 26-12-2012 19:30, Peter H. Coffin wrote:
> On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote:
>> On 26-12-2012 11:43, Tim Streater wrote:
>>> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
>>> 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.
>

But this is an answer, and Jerry only told the OP to check a newsgroup
'for the webserver you are using'

There's a big difference between:
1) Describing (as done here) why this has more to do with the
configuration of your webserver
or
2) Not giving a clue, and pointing to clueless.some.webserver

I whish to thank Peter for his 30 minutes ;)
Re: Current PHP implementation [message #180021 is a reply to message #180020] Wed, 26 December 2012 20:29 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 12/26/2012 2:51 PM, Luuk wrote:
> On 26-12-2012 19:30, Peter H. Coffin wrote:
>> On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote:
>>> On 26-12-2012 11:43, Tim Streater wrote:
>>>> In article <hvvqq9-ept(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
>>>> 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.
>>
>
> But this is an answer, and Jerry only told the OP to check a newsgroup
> 'for the webserver you are using'
>

Which is the CORRECT answer. Point him to the correct place (note he
did NOT say which webserver he's using), and he'll get correct AND
HELPFUL answers (even Peter admitted the answer was probably not helpful).

> There's a big difference between:
> 1) Describing (as done here) why this has more to do with the
> configuration of your webserver
> or
> 2) Not giving a clue, and pointing to clueless.some.webserver
>
> I whish to thank Peter for his 30 minutes ;)

Which is completely worthless in this case because of all the "ifs"
involved. It depends completely on the webserver and the OS it's
running on.

Often times the BEST help one can give someone is to point him at the
RIGHT place to ask his question.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Current PHP implementation [message #180022 is a reply to message #180018] Thu, 27 December 2012 00:54 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Peter H. Coffin wrote:

> Fine. I'll do it. It will be correct, within the contexts of PHP.

And unsurprisingly, what you posted is not even close to being correct, the
PHP part included.

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

No, typically (read: apache-mpm-prefork on a Linux-based system) there will
be two server processes that have 10 threads each, which will continue to
run until the server is shut down.

In any case, with PHP run by server module or FastCGI, the parent process
will like *never* exit as long as the server system is running uninterrupted
(i.e., without reboot and maintenance).

Started threads will likely exist until the Web server service is stopped.
New child processes will be created if the number of threads in a child
process exceed the specified maximum. Threads in a child process will be
created so as to meet the specified minimum and number of spare threads.

> Now, was that helpful?

No.

> Probably not.

So you figured. But you posted this utter nonsense anyway? You have way
too much time on your hands.

> […] You even made me look at a w3sc***ls page to make sure I didn't miss
> something,

There is nothing to be gained from reading a “w3sc***ls page” and much to be
lost. Most of all, clarity of thought and overall mental sanity. Of which
your posting is a good example.

> and now I feel like I need a shower.

Me too.


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
Re: Current PHP implementation [message #180023 is a reply to message #180022] Thu, 27 December 2012 01:31 Go to previous messageGo to next message
Anders Wegge Keller is currently offline  Anders Wegge Keller
Messages: 30
Registered: May 2012
Karma: 0
Member
Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:

> No, typically (read: apache-mpm-prefork on a Linux-based system)
> there will be two server processes that have 10 threads each, which
> will continue to run until the server is shut down.

MaxRequestsPerChild?

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
Re: Current PHP implementation [message #180025 is a reply to message #180023] Thu, 27 December 2012 11:39 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Anders Wegge Keller wrote:

> Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:
>> No, typically (read: apache-mpm-prefork on a Linux-based system)
>> there will be two server processes that have 10 threads each, which
>> will continue to run until the server is shut down.
>
> MaxRequestsPerChild?

Indeed, that is another constraint I overlooked. However, if I am not
mistaken, both the default value and default distribution configuration file
value¹ is 0, which means that those two child processes will never expire,
and AIUI neither will their threads.

<http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild>


PointedEars
___________
¹ I was checking my /etc/apache2/apache2.conf.dpkg-old, mtime 2009-12-04.
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Re: Current PHP implementation [message #180026 is a reply to message #180021] Thu, 27 December 2012 18:37 Go to previous messageGo to next message
Luuk is currently offline  Luuk
Messages: 329
Registered: September 2010
Karma: 0
Senior Member
On 26-12-2012 21:29, Jerry Stuckle wrote:
> On 12/26/2012 2:51 PM, Luuk wrote:
>> On 26-12-2012 19:30, Peter H. Coffin wrote:

......

>> I whish to thank Peter for his 30 minutes ;)
>
> Which is completely worthless in this case because of all the "ifs"
> involved. It depends completely on the webserver and the OS it's
> running on.
>
> Often times the BEST help one can give someone is to point him at the
> RIGHT place to ask his question.
>

I think its more usefull than your first answer.
So, opinions differ.

Also, if you do not know the answer,
than you can also not respond,
in stead of pointing to some other newsgroup
which you did not do in this place,
Because here you tried to send OP to 'somewhere'
Re: Current PHP implementation [message #180027 is a reply to message #180026] Thu, 27 December 2012 21:10 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 12/27/2012 1:37 PM, Luuk wrote:
> On 26-12-2012 21:29, Jerry Stuckle wrote:
>> On 12/26/2012 2:51 PM, Luuk wrote:
>>> On 26-12-2012 19:30, Peter H. Coffin wrote:
>
> .....
>
>>> I whish to thank Peter for his 30 minutes ;)
>>
>> Which is completely worthless in this case because of all the "ifs"
>> involved. It depends completely on the webserver and the OS it's
>> running on.
>>
>> Often times the BEST help one can give someone is to point him at the
>> RIGHT place to ask his question.
>>
>
> I think its more usefull than your first answer.
> So, opinions differ.
>
> Also, if you do not know the answer,
> than you can also not respond,
> in stead of pointing to some other newsgroup
> which you did not do in this place,
> Because here you tried to send OP to 'somewhere'
>

Just because I don't know the answer doesn't mean I can't try to point
him to the right place.

You seem to think ANY answer in this newsgroup - whether related to PHP
or not - is appropriate. But then that's why there are so many crappy
answers to off-topic posts. Direct the person to where the REAL experts
for his/her question hang out is the best advice you can give.

But then I'll bet you'd ask your car mechanic what to do when you're
having a heart attack.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Current PHP implementation [message #180028 is a reply to message #180027] Fri, 28 December 2012 02:28 Go to previous messageGo to next message
Twayne is currently offline  Twayne
Messages: 135
Registered: September 2010
Karma: 0
Senior Member
In news:kbidfq$e8i$1(at)dont-email(dot)me,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
> On 12/27/2012 1:37 PM, Luuk wrote:
>> On 26-12-2012 21:29, Jerry Stuckle wrote:
>>> On 12/26/2012 2:51 PM, Luuk wrote:
>>>> On 26-12-2012 19:30, Peter H. Coffin wrote:
>>
>> .....
>>
....
>
> Just because I don't know the answer doesn't mean I can't
> try to point him to the right place.

Try? When you don't know, shut your trap and don't advertise your ineptness.

>
> You seem to think ANY answer in this newsgroup - whether
> related to PHP or not - is appropriate. But then that's
> why there are so many crappy answers to off-topic posts. Direct the person
> to where the REAL experts for his/her
> question hang out is the best advice you can give.

I havebn't gotten that feeliing about him at all.
>
> But then I'll bet you'd ask your car mechanic what to do
> when you're having a heart attack.

The person having the heart attack isn't going to be doing much of anything;
what do you think he should do?
If the car mech is the only one around, he just might know how to dial 911
or do CPR, or get the fastest help. That's a pretty uriney attituce on your
part and once again makes no sense. An answer for the sake of your ego. A
failure to show off and a lot more.
Re: Current PHP implementation [message #180029 is a reply to message #180028] Fri, 28 December 2012 02:34 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 12/27/2012 9:28 PM, Twayne wrote:
> In news:kbidfq$e8i$1(at)dont-email(dot)me,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
>> On 12/27/2012 1:37 PM, Luuk wrote:
>>> On 26-12-2012 21:29, Jerry Stuckle wrote:
>>>> On 12/26/2012 2:51 PM, Luuk wrote:
>>>> > On 26-12-2012 19:30, Peter H. Coffin wrote:
>>>
>>> .....
>>>
> ...
>>
>> Just because I don't know the answer doesn't mean I can't
>> try to point him to the right place.
>
> Try? When you don't know, shut your trap and don't advertise your ineptness.
>

Ah, the troll speaks up again. How did YOU help him? At least I TRIED
to point him in the right direction!

>>
>> You seem to think ANY answer in this newsgroup - whether
>> related to PHP or not - is appropriate. But then that's
>> why there are so many crappy answers to off-topic posts. Direct the person
>> to where the REAL experts for his/her
>> question hang out is the best advice you can give.
>
> I havebn't gotten that feeliing about him at all.
>>
>> But then I'll bet you'd ask your car mechanic what to do
>> when you're having a heart attack.
>
> The person having the heart attack isn't going to be doing much of anything;
> what do you think he should do?
> If the car mech is the only one around, he just might know how to dial 911
> or do CPR, or get the fastest help. That's a pretty uriney attituce on your
> part and once again makes no sense. An answer for the sake of your ego. A
> failure to show off and a lot more.
>
>
>

Sure, people have heart attacks all the time. A friend of mine even
drove himself to the hospital (I didn't say it was a smart thing to do).

But then you don't know the difference between a heart attack and
cardiac arrest. You don't give CPR to someone with a heart attack (his
heart has not stopped yet).

Once again you show complete ignorance of a subject.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Current PHP implementation [message #180031 is a reply to message #180028] Fri, 28 December 2012 09:18 Go to previous messageGo to next message
Tim Streater is currently offline  Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
Senior Member
In article <kbj045$f78$1(at)speranza(dot)aioe(dot)org>,
"Twayne" <nobody(at)devnull(dot)spamcop(dot)net> wrote:

> If the car mech is the only one around, he just might know how to dial 911

What would that do?

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
Re: Current PHP implementation [message #180034 is a reply to message #180031] Fri, 28 December 2012 16:33 Go to previous message
Paul Herber is currently offline  Paul Herber
Messages: 26
Registered: February 2011
Karma: 0
Junior Member
On Fri, 28 Dec 2012 09:18:00 +0000, Tim Streater <timstreater(at)greenbee(dot)net> wrote:

> In article <kbj045$f78$1(at)speranza(dot)aioe(dot)org>,
> "Twayne" <nobody(at)devnull(dot)spamcop(dot)net> wrote:
>
>> If the car mech is the only one around, he just might know how to dial 911
>
> What would that do?

Probably summons a Porsche mechanic.



--
Regards, Paul Herber, Sandrila Ltd.
http://www.sandrila.co.uk/ twitter: @sandrilaLtd
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Pass varible with out URL and SESSION
Next Topic: Please help clear up some php error notice issue?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 28 13:01:43 GMT 2024

Total time taken to generate the page: 0.06144 seconds