Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #7937 > unrolled thread

Current PHP implementation

Back to article view | Back to comp.lang.php

Contents

  Current PHP implementation "SL@maxis" <noreply@my-rialto.com> - 2012-12-26 09:51 +0800
    Re: Current PHP implementation Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 21:45 -0500
      Re: Current PHP implementation Luuk <luuk@invalid.lan> - 2012-12-26 11:26 +0100
        Re: Current PHP implementation Tim Streater <timstreater@greenbee.net> - 2012-12-26 10:43 +0000
          Re: Current PHP implementation The Natural Philosopher <tnp@invalid.invalid> - 2012-12-26 12:15 +0000
          Re: Current PHP implementation Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-26 08:55 -0500
          Re: Current PHP implementation Luuk <luuk@invalid.lan> - 2012-12-26 17:12 +0100
            Re: Current PHP implementation "Peter H. Coffin" <hellsop@ninehells.com> - 2012-12-26 12:30 -0600
              Re: Current PHP implementation Luuk <luuk@invalid.lan> - 2012-12-26 20:51 +0100
                Re: Current PHP implementation Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-26 15:29 -0500
                  Re: Current PHP implementation Luuk <luuk@invalid.lan> - 2012-12-27 19:37 +0100
                    Re: Current PHP implementation Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-27 16:10 -0500
                      Re: Current PHP implementation "Twayne" <nobody@devnull.spamcop.net> - 2012-12-27 21:28 -0500
                        Re: Current PHP implementation Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-27 21:34 -0500
                        Re: Current PHP implementation Tim Streater <timstreater@greenbee.net> - 2012-12-28 09:18 +0000
                          Re: Current PHP implementation Paul Herber <paul@pherber.com> - 2012-12-28 16:33 +0000
              Re: Current PHP implementation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-27 01:54 +0100
                Re: Current PHP implementation Anders Wegge Keller <wegge@wegge.dk> - 2012-12-27 02:31 +0100
                  Re: Current PHP implementation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-27 12:39 +0100
      Re: Current PHP implementation Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-26 13:45 +0000
    Re: Current PHP implementation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-26 13:40 +0100

Page 1 of 2  [1] 2  Next page →

#7937 — Current PHP implementation

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/

[toc] | [next] | [standalone]

#7939

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7941

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)

?

[toc] | [prev] | [next] | [standalone]

#7942

In article <hvvqq9-ept.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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

[toc] | [prev] | [next] | [standalone]

#7943

On 26/12/12 10:43, Tim Streater wrote:
> In article <hvvqq9-ept.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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.

[toc] | [prev] | [next] | [standalone]

#7946

On 12/26/2012 5:43 AM, Tim Streater wrote:
> In article <hvvqq9-ept.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7948

On 26-12-2012 11:43, Tim Streater wrote:
> In article <hvvqq9-ept.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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

[toc] | [prev] | [next] | [standalone]

#7950

On Wed, 26 Dec 2012 17:12:48 +0100, Luuk wrote:
> On 26-12-2012 11:43, Tim Streater wrote:
>> In article <hvvqq9-ept.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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.

[toc] | [prev] | [next] | [standalone]

#7952

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.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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 ;)

[toc] | [prev] | [next] | [standalone]

#7953

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.ln1@luuk.invalid.lan>, Luuk <luuk@invalid.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7958

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'

[toc] | [prev] | [next] | [standalone]

#7959

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7960

In news:kbidfq$e8i$1@dont-email.me,
Jerry Stuckle <jstucklex@attglobal.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.

[toc] | [prev] | [next] | [standalone]

#7961

On 12/27/2012 9:28 PM, Twayne wrote:
> In news:kbidfq$e8i$1@dont-email.me,
> Jerry Stuckle <jstucklex@attglobal.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7963

In article <kbj045$f78$1@speranza.aioe.org>,
 "Twayne" <nobody@devnull.spamcop.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

[toc] | [prev] | [next] | [standalone]

#7966

On Fri, 28 Dec 2012 09:18:00 +0000, Tim Streater <timstreater@greenbee.net> wrote:

>In article <kbj045$f78$1@speranza.aioe.org>,
> "Twayne" <nobody@devnull.spamcop.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      

[toc] | [prev] | [next] | [standalone]

#7954

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

[toc] | [prev] | [next] | [standalone]

#7955

Thomas 'PointedEars' Lahn <PointedEars@web.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.*

[toc] | [prev] | [next] | [standalone]

#7957

Anders Wegge Keller wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.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.)

[toc] | [prev] | [next] | [standalone]

#7945

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@gmail.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web