[Xotcl] Re: [Xotcl] destroy logic

[Uwe Zdun]

On Thursday 18 January 2001 14:56, Kristoffer Lawson wrote:
> Is operation of the destroy method documented in more detail
> somewhere? What I'm concerned about is how destroy works when method calls
> to an object are still active? Obviously if a method itself calls destroy,
> the object will appear to exist until the method returns. But can this
> method still call other methods?
>

yes. What XOTcl does if it encounters a destroy in a method is to look 
up whether the object is still referenced on the callstack or not. If not,
the object is directly destroyed. Otherwise every occurence of the object's 
command on the callstack is marked as destroyed. During popping of the 
callstack, for each command marked as destroyed, the reference count is 
decremented by one. When no more references to the object are on the callstack
the object is physically destroyed.

Thanks for the hint ... I've just put this explanation into the langRef


> The difficult question, I suppose, is what happens if say a fileevent is
> activated which destroys an object that still has a method running? We are
> coming up with some strange errors in our application for just this kind
> of situation and I'm wondering if in fact the object if destroys when this
> fileevent is run (which would differ from the situation that a method
> itself calls destroy -- which still allows the method itself to run
> normally). The problem is that exactly replicating this isn't easy. It
> pops up in some situations. We get errors like "[self] called after
> destroy" apparently in the middle of a method that is still running, the
> destroy probably coming from an external influence.
>

After an object has left the callstack once, it is in the responsibility of 
the application to care for correct destroys. If that ain't the case, 
probably we have a bug here? Its hard to tell with the given information ... 
if you could isolate a smaller script & send it to me, it would be easier to 
tell what the problem is & how to solve it. 

Unfortunately, its nearly never easy to spot problems with complex 
(asynchronous) object destroys ;)

--Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun at xotcl.org, uwe.zdun at uni-essen.de