Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain adaniels.nl from 82.94.235.198 cause and error)
Message-ID: <45B526AD.2040009@adaniels.nl>
Date: Mon, 22 Jan 2007 22:03:41 +0100
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Lars Schultz <schultz@widescreen.ch>
CC: Stanislav Malyshev <stas@zend.com>, internals@lists.php.net
References: <45B0E1EE.2030102@widescreen.ch> <45B123F5.3070803@zend.com> <45B3929B.8040803@widescreen.ch> <45B51124.90207@zend.com> <45B51AA8.8090307@widescreen.ch>
In-Reply-To: <45B51AA8.8090307@widescreen.ch>
Content-Type: multipart/alternative;
 boundary="------------040700080007010507090307"
Subject: Re: [PHP-DEV] PHP Object-Caching and Reference Counting
From: info@adaniels.nl (Arnold Daniels)

--------------040700080007010507090307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

To get an understanding of zval's and php internal basics, I recommend 
you read the following tutorials:

http://devzone.zend.com/node/view/id/1021 - Part I: Introduction to PHP 
and Zend
http://devzone.zend.com/node/view/id/1022 - Part II: Parameters, Arrays, 
and ZVALs
http://devzone.zend.com/node/view/id/1023 - Part II: Parameters, Arrays, 
and ZVALs (continued)
http://devzone.zend.com/node/view/id/1024 - Part III: Resources

(Hmm this is the 3rd time I advertise these tutorials, I should get paid 
for it :p )

Best regards,
Arnold


Lars Schultz schreef:
>
>> That's correct. However, it is not guaranteed that your unset would 
>> delete last reference - there can be references on stack, in temp 
>> variables in current expressions being calculated (function call 
>> could happen in mid-expression), etc. Of course, it might be that 
>> your code is very controlled so you know it never happens, but as 
>> general case you can't rely on it.
>
> Ok. I got your point. You are right that it's hard to predict where 
> references could be found.
>
>> Also, if you check only zval refcount, you might unset objects that 
>> actually are referenced from other places but by different zvals, 
>> since one object could be referenced by a number of zvals.
>
> I am not familiar with the term: "zval"...My understanding of php 
> comes from extensive usage...Can you give me a specific example?
>
> $foo = new MyObject();      //ref count to Object #1 is 1
> $bar = $foo;                        //ref count to Object #1 is 2
> if ( ($zapp = $bar)->doIt() ) {...} //ref count is 3 or 4? but it 
> doesn't matter really...
>
> I also believe that my reasons for this feature only require that 
> there are not any less references than are returned by ref_count()...I 
> am aware that the usage is for quite an advanced concept...but why 
> shouldn't PHP also be used for this.
>
> The one argument against this feature that carries the most weight, 
> for me, is that PHP might change the behaviour of its memory 
> management and then keeping count of references would be an unecessary 
> overhead, which might lead to my code not working anymore if the 
> feature were to be dropped. Are there likely to be any changes in the 
> future?...and is there an other solution to this concept? I find it 
> rather neat...;) Especially if you couple it with the magic function 
> __wake() where the objects re-register themselves in the cache-list...
>
> <?
> class MyObject {
>    ...
>    public function __wake(){
>       self::$instances[$this->id] = $this;
>    }
>    ...
> }
> ?>
>
> In this case all objects not referenced by any variable in the 
> $_SESSION array (or it's descendants), would be destructed at the end 
> of the script. This way the objects remain unique even across sessions 
> and some kind of cleaning up is done by the serialization process. The 
> trouble is that this only works at the end of the script where of 
> course even the current stack is not used anymore. So I can't use this 
> principle in a function-call. Or does anyone of you have a different 
> solution?;)
>

--------------040700080007010507090307--