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?
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.
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
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
On Thu, 18 Jan 2001, Uwe Zdun wrote:
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 ;)
Yes, this is exactly why explaining, and even reproducing the problem is difficult. In any case, I do believe we probably have found a bug, as a method is being run and while it is run at some point it gets a message that [self] called after destroy, or something like that. Thus we've had to work around this in a rather complex fashion. I'll try to explain it as best I can:
A method "event" of object "ob" is called as a result of an external event -- like user input. This object then reads protocol data from a socket and acts on commands sent to it. These commands it executes via another different object "ob2". In our case, one of these commands happens to be a RM command, which after sending to this ob2 results in ob2 calling the destroy method for ob. After this calls to [self] inside the "event" method (which is still running at this point) cause an immediate error.
Do you think you can work that out? ;-)
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
On Thu, 18 Jan 2001, Kristoffer Lawson wrote:
Yes, this is exactly why explaining, and even reproducing the problem is difficult. In any case, I do believe we probably have found a bug, as a method is being run and while it is run at some point it gets a message that [self] called after destroy, or something like that. Thus we've had to work around this in a rather complex fashion. I'll try to explain it as best I can:
Found the problem:
On the machine the guy is running, the version of XOTcl is 0.81, which bugs in the case described. He's now upgrading...
Doh.
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
-
Kristoffer Lawson -
Uwe Zdun