| php daemon [message #179589] |
Sun, 11 November 2012 17:18  |
SL
Messages: 20
Registered: February 2012
Karma: 0
|
Junior Member |
|
|
Anybody has experience of running php program as daemon ?
Would explicitly allocating and de-allocating all variables/memories be
effective for managing php daemon ?
Thanks.
|
|
|
|
| Re: php daemon [message #179591 is a reply to message #179589] |
Sun, 11 November 2012 19:04  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2012 12:18 PM, sl@exabyte wrote:
> Anybody has experience of running php program as daemon ?
>
> Would explicitly allocating and de-allocating all variables/memories be
> effective for managing php daemon ?
>
> Thanks.
>
>
Personally, I don't think PHP would make a good daemon. Among other
things, you cannot manage memory yourself. All you can do is unset()
variables. However, this does not release memory immediately. It would
wait for the garbage collector to run.
When I'm writing daemons, I use C or C++. They are much more
appropriate, IMHO.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179592 is a reply to message #179591] |
Sun, 11 November 2012 20:05 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> All you can do is unset() variables. However, this does not release
> memory immediately. It would wait for the garbage collector to run.
I'm very much surprised. I /assumed/ that PHP uses reference counting,
which would typically release the allocated memory as soon as the
reference count of a value is 0.
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179593 is a reply to message #179592] |
Sun, 11 November 2012 20:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2012 3:05 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> All you can do is unset() variables. However, this does not release
>> memory immediately. It would wait for the garbage collector to run.
>
> I'm very much surprised. I /assumed/ that PHP uses reference counting,
> which would typically release the allocated memory as soon as the
> reference count of a value is 0.
>
It does. But memory is not released until the garbage collector is run.
See the PHP documentation.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179594 is a reply to message #179593] |
Sun, 11 November 2012 21:22 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 11/11/2012 3:05 PM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> All you can do is unset() variables. However, this does not release
>>> memory immediately. It would wait for the garbage collector to run.
>>
>> I'm very much surprised. I /assumed/ that PHP uses reference counting,
>> which would typically release the allocated memory as soon as the
>> reference count of a value is 0.
>>
>
> It does. But memory is not released until the garbage collector is run.
> See the PHP documentation.
Thanks for the pointer to the PHP documentation. According to
<http://php.net/manual/en/features.gc.refcounting-basics.php>:
| A PHP variable is stored in a container called a "zval". A zval
| container contains, besides the variable's type and value, two
| additional bits of information.
| [...]
| Variable containers get destroyed when the "refcount" reaches zero.
| [...]
| Again, when the "refcount" reaches zero, the variable container is
| removed from memory.
As this simple reference counting garbage collection isn't able to free
circular structures, a garbage collector [1] to do so was introduced in
PHP 5.3. Unfortunately the documentation isn't particularly clear here:
| If the refcount is decreased and hits zero, the zval can be freed.
But from the subsequent documentation I conclude, that the zval is
actually freed, when the refcount is decreased to zero.
[1] <http://www.php.net/manual/en/features.gc.collecting-cycles.php
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179595 is a reply to message #179594] |
Sun, 11 November 2012 21:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2012 4:22 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> On 11/11/2012 3:05 PM, Christoph Becker wrote:
>>> Jerry Stuckle wrote:
>>>> All you can do is unset() variables. However, this does not release
>>>> memory immediately. It would wait for the garbage collector to run.
>>>
>>> I'm very much surprised. I /assumed/ that PHP uses reference counting,
>>> which would typically release the allocated memory as soon as the
>>> reference count of a value is 0.
>>>
>>
>> It does. But memory is not released until the garbage collector is run.
>> See the PHP documentation.
>
> Thanks for the pointer to the PHP documentation. According to
> <http://php.net/manual/en/features.gc.refcounting-basics.php>:
>
> | A PHP variable is stored in a container called a "zval". A zval
> | container contains, besides the variable's type and value, two
> | additional bits of information.
> | [...]
> | Variable containers get destroyed when the "refcount" reaches zero.
> | [...]
> | Again, when the "refcount" reaches zero, the variable container is
> | removed from memory.
>
> As this simple reference counting garbage collection isn't able to free
> circular structures, a garbage collector [1] to do so was introduced in
> PHP 5.3. Unfortunately the documentation isn't particularly clear here:
>
> | If the refcount is decreased and hits zero, the zval can be freed.
>
> But from the subsequent documentation I conclude, that the zval is
> actually freed, when the refcount is decreased to zero.
>
> [1] <http://www.php.net/manual/en/features.gc.collecting-cycles.php
>
No, that is the purpose of the garbage collector - which runs
occasionally at times determined by the php.ini file.
Notice the documentation says the zval CAN be freed - not the zval WILL
be freed. Two entirely different statements.
This is for performance reasons. It is much more to the running script
efficient to free a group of unused pieces of memory asynchronously than
to free the memory synchronously (every time the refcount goes to zero).
Note that PHP is not the only language to do it this way. Java does
also, for instance.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179596 is a reply to message #179595] |
Sun, 11 November 2012 22:17 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> Notice the documentation says the zval CAN be freed - not the zval WILL
> be freed. Two entirely different statements.
ACK. I had noted that; therefore I wrote that the manual isn't very
clear in this (IMO important) regard. "can" does neither imply nor
exclude, that it "will" be done.
I've made the following test:
$a = uniqid(); // force dynamic memory allocation
echo memory_get_usage(), "\n";
$a = 'foo'; // don't unset($a), as this will change the "symbol table"
echo memory_get_usage(), "\n";
gc_collect_cycles(); // force garbage collection
echo memory_get_usage(), "\n";
The result with my PHP 5.4.7 on Windows XP:
121344
121304
121304
So either the zval holding the result of uniqid() is already freed, when
$a is set to 'foo', or gc_collect_cycles() doesn't actually trigger the
garbage collector in this case.
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179597 is a reply to message #179596] |
Sun, 11 November 2012 23:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2012 5:17 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Notice the documentation says the zval CAN be freed - not the zval WILL
>> be freed. Two entirely different statements.
>
> ACK. I had noted that; therefore I wrote that the manual isn't very
> clear in this (IMO important) regard. "can" does neither imply nor
> exclude, that it "will" be done.
>
> I've made the following test:
>
> $a = uniqid(); // force dynamic memory allocation
> echo memory_get_usage(), "\n";
> $a = 'foo'; // don't unset($a), as this will change the "symbol table"
> echo memory_get_usage(), "\n";
> gc_collect_cycles(); // force garbage collection
> echo memory_get_usage(), "\n";
>
> The result with my PHP 5.4.7 on Windows XP:
>
> 121344
> 121304
> 121304
>
> So either the zval holding the result of uniqid() is already freed, when
> $a is set to 'foo', or gc_collect_cycles() doesn't actually trigger the
> garbage collector in this case.
>
Or, memory_get_usage() does not count memory which has been marked as
unused but not freed yet.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179600 is a reply to message #179597] |
Mon, 12 November 2012 13:35 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> Or, memory_get_usage() does not count memory which has been marked as
> unused but not freed yet.
Indeed, that's another possibility. But then the documentation would be
misleading:
| memory_get_usage — Returns the amount of memory allocated to PHP
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179602 is a reply to message #179600] |
Mon, 12 November 2012 13:38 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/12/2012 8:35 AM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Or, memory_get_usage() does not count memory which has been marked as
>> unused but not freed yet.
>
> Indeed, that's another possibility. But then the documentation would be
> misleading:
>
> | memory_get_usage — Returns the amount of memory allocated to PHP
>
If you think the documentation is misleading then you should file a bug
report. I don't think you'll get too far, but you can try.
Personally, I find it quite clear as to what happens.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179604 is a reply to message #179591] |
Mon, 12 November 2012 15:45 |
SL
Messages: 20
Registered: February 2012
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle wrote:
>
> Personally, I don't think PHP would make a good daemon. Among other
> things, you cannot manage memory yourself. All you can do is unset()
> variables. However, this does not release memory immediately. It
> would wait for the garbage collector to run.
>
> When I'm writing daemons, I use C or C++. They are much more
> appropriate, IMHO.
Thanks for your useful inputs gentlemen.
I sort of has given up hope for a daemon in PHP. I thought I can use its
memory allocation functions directly, it turns out not. Even if I can, there
is still garbage collector to contend with.
A helper mechanism has turned anti-mechanism in this case. :-(
|
|
|
|
| Re: php daemon [message #179605 is a reply to message #179604] |
Mon, 12 November 2012 16:08 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/11/12 15:45, sl@exabyte wrote:
> Jerry Stuckle wrote:
>>
>> Personally, I don't think PHP would make a good daemon. Among other
>> things, you cannot manage memory yourself. All you can do is unset()
>> variables. However, this does not release memory immediately. It
>> would wait for the garbage collector to run.
>>
>> When I'm writing daemons, I use C or C++. They are much more
>> appropriate, IMHO.
>
> Thanks for your useful inputs gentlemen.
>
> I sort of has given up hope for a daemon in PHP. I thought I can use its
> memory allocation functions directly, it turns out not. Even if I can, there
> is still garbage collector to contend with.
>
> A helper mechanism has turned anti-mechanism in this case. :-(
>
>
anything you can write in PHP you can write better and faster in C anyway..
I had a look at php for daemons and decided that the disadvantages
outweighed the very few advantages., Its great for spitting out HTML,
but I have seen issues with it with non re-entrant libraries even just
running concurrent sessions from multiple web browsers.
Horses for courses.
--
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: php daemon [message #179610 is a reply to message #179589] |
Tue, 13 November 2012 07:57 |
Goran
Messages: 38
Registered: January 2011
Karma: 0
|
Member |
|
|
On 11.11.2012 18:18, sl@exabyte wrote:
> Anybody has experience of running php program as daemon ?
>
> Would explicitly allocating and de-allocating all variables/memories be
> effective for managing php daemon ?
PHP daemons are common pattern in some situations. E.g. how would you
implement AMQP listener without daemon?
But, due to the stateless nature of web, PHP is not made for daemonizing
:) Fortunately, there is solution, just keep in mind the following:
1. don't overuse this possibility - avoid it if you can
2. don't depend on PHP's memory management - shutdown your script
automatically from time to time just to be safe of memory leakage
3. auto start it immediately after shutdown - use supervisord
Basically, do this:
<?php
define('MAX_ITERATIONS', 10);
for ($iteration = 0; $iteration < MAX_ITERATIONS; $iteration++)
{
// Do something nasty
// ...
sleep(10);
}
?>
|
|
|
|
| Re: php daemon [message #179613 is a reply to message #179600] |
Tue, 13 November 2012 12:44 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/12/2012 8:35 AM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Or, memory_get_usage() does not count memory which has been marked as
>> unused but not freed yet.
>
> Indeed, that's another possibility. But then the documentation would be
> misleading:
>
> | memory_get_usage — Returns the amount of memory allocated to PHP
>
I thought of something else you may be misunderstanding. This is NOT
the amount of memory allocated to PHP by the OS. That is in multiples
of 4K blocks (for Intel architecture). It is the amount actually
allocated for use by PHP. Once that figure reaches the maximum memory
defined in the php.ini file, no more memory can be allocated by the
script.
Your interpretation would provide pretty worthless information as it
would not give a true account of memory being used.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179614 is a reply to message #179610] |
Tue, 13 November 2012 12:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/13/2012 2:57 AM, Goran wrote:
> On 11.11.2012 18:18, sl@exabyte wrote:
>> Anybody has experience of running php program as daemon ?
>>
>> Would explicitly allocating and de-allocating all variables/memories be
>> effective for managing php daemon ?
>
> PHP daemons are common pattern in some situations. E.g. how would you
> implement AMQP listener without daemon?
>
I'd do it in C or C++.
> But, due to the stateless nature of web, PHP is not made for daemonizing
> :) Fortunately, there is solution, just keep in mind the following:
>
It has nothing to do with the stateless nature of the web. PHP is good
for non-web projects, also. And C and other languages can be used for
the web.
> 1. don't overuse this possibility - avoid it if you can
> 2. don't depend on PHP's memory management - shutdown your script
> automatically from time to time just to be safe of memory leakage
> 3. auto start it immediately after shutdown - use supervisord
>
> Basically, do this:
>
> <?php
>
> define('MAX_ITERATIONS', 10);
>
> for ($iteration = 0; $iteration < MAX_ITERATIONS; $iteration++)
> {
> // Do something nasty
> // ...
>
> sleep(10);
> }
>
> ?>
>
What a kludge.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179616 is a reply to message #179614] |
Tue, 13 November 2012 13:54 |
Goran
Messages: 38
Registered: January 2011
Karma: 0
|
Member |
|
|
On 13.11.2012 13:47, Jerry Stuckle wrote:
> I'd do it in C or C++.
Ok, let's all hire the C daemon guy, explain this to human resources
department...
> What a kludge.
Wll, life is a kludge too
|
|
|
|
| Re: php daemon [message #179617 is a reply to message #179616] |
Tue, 13 November 2012 14:13 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 13/11/12 13:54, Goran wrote:
> On 13.11.2012 13:47, Jerry Stuckle wrote:
>> I'd do it in C or C++.
>
> Ok, let's all hire the C daemon guy, explain this to human resources
> department...
>
Oh FFS its hardly rocket science to write a basic daemon with all the
crib code out there.
>> What a kludge.
>
> Wll, life is a kludge too
>
--
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: php daemon [message #179618 is a reply to message #179616] |
Tue, 13 November 2012 17:23 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/13/2012 8:54 AM, Goran wrote:
> On 13.11.2012 13:47, Jerry Stuckle wrote:
>> I'd do it in C or C++.
>
> Ok, let's all hire the C daemon guy, explain this to human resources
> department...
>
Yes, let's do it right. You could also contract it out.
>> What a kludge.
>
> Wll, life is a kludge too
>
Sorry to hear your's is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179621 is a reply to message #179618] |
Wed, 14 November 2012 07:43 |
Goran
Messages: 38
Registered: January 2011
Karma: 0
|
Member |
|
|
On 13.11.2012 18:23, Jerry Stuckle wrote:
>> Ok, let's all hire the C daemon guy, explain this to human resources
>> department...
> Yes, let's do it right. You could also contract it out.
There is nothing wrong with PHP daemons. As I mentioned, example I wrote
is common pattern in PHP world so it is proven solution.
But yes, if you are lazy enough you could hire C programmer.
> Sorry to hear your's is.
Oh, it's personal now?
|
|
|
|
| Re: php daemon [message #179622 is a reply to message #179621] |
Wed, 14 November 2012 10:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2012 2:43 AM, Goran wrote:
> On 13.11.2012 18:23, Jerry Stuckle wrote:
>>> Ok, let's all hire the C daemon guy, explain this to human resources
>>> department...
>> Yes, let's do it right. You could also contract it out.
>
> There is nothing wrong with PHP daemons. As I mentioned, example I wrote
> is common pattern in PHP world so it is proven solution.
> But yes, if you are lazy enough you could hire C programmer.
>
Yes, it is a common pattern for people who don't know better.
Knowledgeable programmers understand PHP is not a good language to write
daemons. They use an appropriate language which doesn't have to resort
to such kludges.
>> Sorry to hear your's is.
>
> Oh, it's personal now?
>
You're the one who claimed life's a kludge, so yours must be. Mine isn't.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179623 is a reply to message #179613] |
Wed, 14 November 2012 20:19 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> I thought of something else you may be misunderstanding. This is NOT
> the amount of memory allocated to PHP by the OS. That is in multiples
> of 4K blocks (for Intel architecture). It is the amount actually
> allocated for use by PHP. Once that figure reaches the maximum memory
> defined in the php.ini file, no more memory can be allocated by the script.
I'm aware of the $real_usage parameter of memory_get_usage() and the
different results reported according to the value of this parameter.
And I assume, that the following invariant holds:
memory_get_usage(true) >= memory_get_usage(false)
> Your interpretation would provide pretty worthless information as it
> would not give a true account of memory being used.
Isn't the true amount of memory being used by PHP (independent on how
much is allocated by the OS) the relevant information for the given test?
However, reading
<http://www.php.net/manual/en/features.gc.collecting-cycles.php> and
<https://wiki.php.net/internals/zend_mm> still let's me assume, that
zvals which refcount drops to zero are immediately freed (/not
necessarily given back to the OS, though/). The following test
/supports/ my assumption (it's no prove, though):
for ($i = 0; $i < 99; $i++) {
for ($j = 0; $j < 10000; $j++) {
$a = uniqid();
}
echo memory_get_usage(true), "\n";
}
Even if 990,000 uniqid()s (having 13 bytes each) will be allocated, on
my PHP 5.4.7 on Windows XP the output are 99 lines with 262144,
independent of the setting of zend.enable_gc.
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179624 is a reply to message #179623] |
Wed, 14 November 2012 21:33 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2012 3:19 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> I thought of something else you may be misunderstanding. This is NOT
>> the amount of memory allocated to PHP by the OS. That is in multiples
>> of 4K blocks (for Intel architecture). It is the amount actually
>> allocated for use by PHP. Once that figure reaches the maximum memory
>> defined in the php.ini file, no more memory can be allocated by the script.
>
> I'm aware of the $real_usage parameter of memory_get_usage() and the
> different results reported according to the value of this parameter.
> And I assume, that the following invariant holds:
>
> memory_get_usage(true) >= memory_get_usage(false)
>
>> Your interpretation would provide pretty worthless information as it
>> would not give a true account of memory being used.
>
> Isn't the true amount of memory being used by PHP (independent on how
> much is allocated by the OS) the relevant information for the given test?
>
Yes, and if a variable has been unset, it's storage is no longer being
used by PHP. It's in the pool to be cleaned up by the garbage
collector, but that's different.
> However, reading
> <http://www.php.net/manual/en/features.gc.collecting-cycles.php> and
> <https://wiki.php.net/internals/zend_mm> still let's me assume, that
> zvals which refcount drops to zero are immediately freed (/not
> necessarily given back to the OS, though/). The following test
> /supports/ my assumption (it's no prove, though):
>
> for ($i = 0; $i < 99; $i++) {
> for ($j = 0; $j < 10000; $j++) {
> $a = uniqid();
> }
> echo memory_get_usage(true), "\n";
> }
>
> Even if 990,000 uniqid()s (having 13 bytes each) will be allocated, on
> my PHP 5.4.7 on Windows XP the output are 99 lines with 262144,
> independent of the setting of zend.enable_gc.
>
That is correct.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179625 is a reply to message #179624] |
Wed, 14 November 2012 22:13 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> Yes, and if a variable has been unset, it's storage is no longer being
> used by PHP. It's in the pool to be cleaned up by the garbage
> collector, but that's different.
But what happens, if the garbage collector is disabled? [1] Would none
of the allocated memory be freed?
[1] zend.enable_gc boolean
Enables or disables the circular reference collector.
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179635 is a reply to message #179625] |
Thu, 15 November 2012 12:41 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2012 5:13 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Yes, and if a variable has been unset, it's storage is no longer being
>> used by PHP. It's in the pool to be cleaned up by the garbage
>> collector, but that's different.
>
> But what happens, if the garbage collector is disabled? [1] Would none
> of the allocated memory be freed?
>
> [1] zend.enable_gc boolean
> Enables or disables the circular reference collector.
>
Why don't you try it and find out?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179638 is a reply to message #179622] |
Thu, 15 November 2012 13:08 |
Goran
Messages: 38
Registered: January 2011
Karma: 0
|
Member |
|
|
On 14.11.2012 11:51, Jerry Stuckle wrote:
> You're the one who claimed life's a kludge, so yours must be. Mine isn't.
As I can see, you tend to overcomplicate things, that's why I believe
your life is a mess.
> Yes, it is a common pattern for people who don't know better.
Maybe it's time for you to start defining what's wrong with my example
(after so much bs talk). Define kludge.
|
|
|
|
| Re: php daemon [message #179640 is a reply to message #179638] |
Thu, 15 November 2012 13:46 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/15/2012 8:08 AM, Goran wrote:
> On 14.11.2012 11:51, Jerry Stuckle wrote:
>> You're the one who claimed life's a kludge, so yours must be. Mine isn't.
>
> As I can see, you tend to overcomplicate things, that's why I believe
> your life is a mess.
>
Nope, you're the one who had to put together a kludge instead of using a
more appropriate language.
>> Yes, it is a common pattern for people who don't know better.
>
> Maybe it's time for you to start defining what's wrong with my example
> (after so much bs talk). Define kludge.
>
You have to keep stopping and starting it, for one thing. And in your
loop you need to sleep() for a while.
And you confuse the "stateless nature of the web" with daemons - they
have nothing to do with each other.
Or maybe you don't understand what a daemon is, or how a *real* daemon
works.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: php daemon [message #179642 is a reply to message #179640] |
Thu, 15 November 2012 15:09 |
Goran
Messages: 38
Registered: January 2011
Karma: 0
|
Member |
|
|
On 15.11.2012 14:46, Jerry Stuckle wrote:
> On 11/15/2012 8:08 AM, Goran wrote:
>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>> You're the one who claimed life's a kludge, so yours must be. Mine
>>> isn't.
>>
>> As I can see, you tend to overcomplicate things, that's why I believe
>> your life is a mess.
>>
>
> Nope, you're the one who had to put together a kludge instead of using a
> more appropriate language.
I guess you are the kind of person which prefer to buy a car instead of
paying for single taxi drive.
>>> Yes, it is a common pattern for people who don't know better.
>>
>> Maybe it's time for you to start defining what's wrong with my example
>> (after so much bs talk). Define kludge.
>>
>
> You have to keep stopping and starting it, for one thing. And in your
> loop you need to sleep() for a while.
Every daemon needs loop, sleep is completely optional in every language
(it's just an example). Whats wrong with restarting? It's not your job,
it's supervisord's job. Even regular daemons need autorestarting for
failover sometimes.
> And you confuse the "stateless nature of the web" with daemons - they
> have nothing to do with each other.
You took it out of context, how appropriate...
PHP is scripting language primarily made for web - not designed to deal
with long running applications. Therefor, it's memory management is not
so precise - it's optimized for performance, not for memory usage.
Therefore, it's ideal for "stateless nature of the web", because there
is no need to carry state among http requests.
Although, it's suboptimal for daemons, with a little help of supervisord
it can be efficient enough.
> Or maybe you don't understand what a daemon is, or how a *real* daemon
> works.
You know what? My dad eat daemons for breakfast!
|
|
|
|
| Re: php daemon [message #179647 is a reply to message #179635] |
Thu, 15 November 2012 15:55 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 11/14/2012 5:13 PM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> Yes, and if a variable has been unset, it's storage is no longer being
>>> used by PHP. It's in the pool to be cleaned up by the garbage
>>> collector, but that's different.
>>
>> But what happens, if the garbage collector is disabled? [1] Would none
>> of the allocated memory be freed?
>>
>> [1] zend.enable_gc boolean
>> Enables or disables the circular reference collector.
>>
>
> Why don't you try it and find out?
I did that already yesterday, posted the example code and the results,
and you've commented it with "That is correct." So it was merely a
rethoric question.
--
Christoph M. Becker
|
|
|
|
| Re: php daemon [message #179649 is a reply to message #179640] |
Thu, 15 November 2012 16:20 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <k82rn7$fgl$1(at)dont-email(dot)me>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
> On 11/15/2012 8:08 AM, Goran wrote:
>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>> You're the one who claimed life's a kludge, so yours must be. Mine isn't.
>>
>> As I can see, you tend to overcomplicate things, that's why I believe
>> your life is a mess.
>>
>
> Nope, you're the one who had to put together a kludge instead of using a
> more appropriate language.
>
>>> Yes, it is a common pattern for people who don't know better.
>>
>> Maybe it's time for you to start defining what's wrong with my example
>> (after so much bs talk). Define kludge.
>>
>
> You have to keep stopping and starting it, for one thing. And in your
> loop you need to sleep() for a while.
I haven't looked into whether PHP offers any such facilities, but what
should really be happening is:
wait ();
where the wait is exited if an event occurs. It would require the
capability to declare something to be an event and to queue a work item
when the event occurs, etc etc.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: php daemon [message #179650 is a reply to message #179642] |
Thu, 15 November 2012 16:25 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/15/2012 10:09 AM, Goran wrote:
> On 15.11.2012 14:46, Jerry Stuckle wrote:
>> On 11/15/2012 8:08 AM, Goran wrote:
>>> On 14.11.2012 11:51, Jerry Stuckle wrote:
>>>> You're the one who claimed life's a kludge, so yours must be. Mine
>>>> isn't.
>>>
>>> As I can see, you tend to overcomplicate things, that's why I believe
>>> your life is a mess.
>>>
>>
>> Nope, you're the one who had to put together a kludge instead of using a
>> more appropriate language.
>
> I guess you are the kind of person which prefer to buy a car instead of
> paying for single taxi drive.
>
Absolutely nothing to do with the question. I prefer to do it *right*.
>>>> Yes, it is a common pattern for people who don't know better.
>>>
>>> Maybe it's time for you to start defining what's wrong with my example
>>> (after so much bs talk). Define kludge.
>>>
>>
>> You have to keep stopping and starting it, for one thing. And in your
>> loop you need to sleep() for a while.
>
> Every daemon needs loop, sleep is completely optional in every language
> (it's just an example). Whats wrong with restarting? It's not your job,
> it's supervisord's job. Even regular daemons need autorestarting for
> failover sometimes.
>
Yes, but good daemons don't need to stop and restart. They also don't
use sleep().
As for restarting - extra overhead on the processor, for one thing. But
mainly the daemon loses any existing values, and is not available during
the restart procedure.
I can imagine how far an ftp server daemon would go if you had to log on
after every ten blocks were uploaded!
>> And you confuse the "stateless nature of the web" with daemons - they
>> have nothing to do with each other.
>
> You took it out of context, how appropriate...
>
Nope. You're the one who mentioned them together.
> PHP is scripting language primarily made for web - not designed to deal
> with long running applications. Therefor, it's memory management is not
> so precise - it's optimized for performance, not for memory usage.
> Therefore, it's ideal for "stateless nature of the web", because there
> is no need to carry state among http requests.
>
PHP is written as a web language, but it's also good for scripting
files. And no, it is not "optimized for performance". It is "optimized
for ease of coding". PHP performance is actually pretty bad when
compared to other languages like C. But while you *can* use C for web
projects, it is not a good choice, IMHO.
And yes, there is a need for carrying state amongst http requests.
That's what $_SESSION is all about.
> Although, it's suboptimal for daemons, with a little help of supervisord
> it can be efficient enough.
>
It's crap for daemons. It was never meant to be used for them. But
then there are always people why try to use a hammer when a screwdriver
is more appropriate.
>> Or maybe you don't understand what a daemon is, or how a *real* daemon
>> works.
>
> You know what? My dad eat daemons for breakfast!
>
I can believe that!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]