Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <22319.204.16.229.245.1165342794.squirrel@www.l-i-e.com>
In-Reply-To: <4574C97F.8020507@adaniels.nl>
References:  <4574C97F.8020507@adaniels.nl>
Date: Tue, 5 Dec 2006 12:19:54 -0600 (CST)
To: "Arnold Daniels" <info@adaniels.nl>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] destruction of cross-referenced objects
From: ceo@l-i-e.com ("Richard Lynch")

On Mon, December 4, 2006 7:21 pm, Arnold Daniels wrote:
> I'm struggling with the problem that cross-referenced objects don't
> get
> destroyed. I can off course write a method to break the
> cross-reference,
> but that's kind of a pain in the butt, especially if the
> cross-reference
> is not strait forward.

Seems to me that a simple unset() on the data members in userland
coude so PHPs refcount is decremented ought to do it...

If a user creates a monstrous data structure and doesn't prune it, how
much responsibility can PHP take for that?

But maybe I'm just being naive.

> To solve this I'm thinking of building one of 2 thing:
> 1.) Write a destroy() function which works much like a close function
> on
> a recourse, changing the object to a zval of type 'unknown'.
> 2.) Specify that a property of an object does not count for the
> reference count of a zval.

I don't think this is a Good Idea...

Seems like it would be WAY too easy for userland code to end up with a
0 for the refcount and then GC kicks in.

> 3.) Write code to find cross-references and destroy the objects still.
>
> The first solution should be quite easy to implement, but you need to
> call destroy() to free the object, introducing the whole alloc/free
> responsibility thing to PHP.

Just use unset() for this, rather than introduce yet another confusing
function.

> The second solution would require some extra keyword within the class,
> but require no special code within the code using the object. Though I
> wouldn't have a clue how how to implement this or what would be the
> consequences.

> I don't think the third solution is really possible or would at least
> cause performance problems.

Finding a "dead branch" of cyclic structures is basic CS stuff.

Add a second temp "refcount" and start walking the graph.

Either you end up with something known to be in the GLOBAL scope, or
you don't.

It can take a long time, depending on the size of the graph, but it's
just pointer-chasing and integer arithmetic, so shouldn't be THAT
slow.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?