On Tue, December 5, 2006 4:45 pm, Arnold Daniels wrote: > Richard Lynch schreef: >> 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. >> >> > I myself run into problems when implementing parent/child > relationships > within object. I probably use PHP a bit different than the regular > user > and therefor run into different problems, but with more elaborate > frameworks being build, I think more people will run into these kind > of > problems. > Think about a DOM implementation fully in PHP (I'm not building that, > but just to give you an idea). Using uset() on each child wouldn't do > much good, since each also holds a parent/child relationship with its > children and therefor the child is not destroyed, meaning the parent > is > not destroyed. To overcome this you need implement a method destroy(), > which runs through all property to see if it is a DOM object and call > the destroy() on it. But now imagine another class which has > properties > with objects of all kinds of classes, some of which have parent/child > relationships. Now you need all these classes to implement some sort > of > destroyable interface. I don't really like a solution like this. With > the destroy function you would still need to walk through the children > and call destroy forcing an unset in the destructor of the class, but > it's a step up.
I could be full of it, as I don't do PHP OOP that much, but it seems to me that if your __dtor (or whatever it is in PHP) walks through the members and unset()s them to not point to the parent/child any more, in a structured way so that you don't chop off your own foot, then you will not create these giant cyclic un-salvagable data structures. If you don't do that, then, yes, PHP will most likely not be able to track your data storage for you. >> 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. >> >> > I don't really see this solution. I wouldn't unnecessarily find > anything > in the GLOBAL scope. When using unset or returning from a function, a > check should be made to find if the variable is used within the scope > of > the call stack, global or statically. To my knowledge (which is > small > on the PHP internals subject) it is only possible to see how many > references to the object there are, not where there references are. If it's on the function stack and it's not global nor static, then it should be free'd when the function ends. If it's global, then it's got to be pointed to by SOME data node within $_GLOBALS for you to be able to reach it, no? Hmmm, maybe not, with eval() and variable variables... Except that ultimately, eval() and variable variables can only refer back to some pre-existing variable to chase down the data, and that has to somehow be linked back to *something* in $_GLOBALS, doesn't it?... Let me think on that for awhile... > Thank you for commenting on my e-mail. I hope you understand where I'm > coming from with this problem and understand why unset will not do. I > hope that you or perhaps someone else might have some other comments > or > solutions I haven't yet thought of. I truly believe that if you are putting that much faith/reliance in PHP's GC and refcount values, then you've probably got a data structure that needs some more effort in maintenance and needs to clean up after itself, rather than rely on the semi-random timing of PHP's GC. So it's not that you couldn't improve PHP to do it for you -- It's that you'd be attacking the symptom rather than the disease. :-) -- 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
