[Xotcl] Object destruction on exit

[Gustaf Neumann]

Jeff Hobbs schrieb:
> Gustaf Neumann wrote:
>   
>> Kristoffer Lawson schrieb:
>>     
>>> When XOTcl exits, it seems that the [destroy] method is called on all
>>> objects. The first question is whether this is wise .. possibly. 
>>>       
>> well, it was some work to do so, and i think this is 
>> important from the oo-point-of-view.
>>     
>
> Some work to enable?  The general deletion of a Tcl interpreter
> will call any associated deletion callback for AssocData and
> commands.  The one exception is for the last interpreter in a
> "common" shell environment, which doesn't get deleted normally
> (unless exit is undefined or you compile with -DPURIFY).
>   
i am quite satisfied with the current behavior of tcl. we have various 
compile
flags already in xotcl to control the behavior, mostly for debugging 
memory leaks etc.
(not unisimilar to the -DPURIFY motivation in Tcl core). And yes, we are 
treating
"interp exit" and "last interp exist" differently internally.

>> If one allocates "external resources" (e.g. temp-files, register on a 
>> whiteboard, etc)
>> and deallocates these resources in a destructor, the 
>> deallocation should certainly
>> happen, when the program exists gracefully.
>>     
>
> The graceful deallocation argument is mostly spurious, as the OS
> cleans things up on program exit, but freeing of external
> resources is important.  
exactly.
> This is why I'm considering fixing that
> "last interp" exception above.
>   
i am not sure that this would simplify the xotcl exit behavior 
significantly.
The biggest problem was to get the deletion order within a namespace
correct. since objects and classes are cmds in a namespace's has table,
standard tcl deletion does not care about the deletion order. xotcl
has to care about this: if we have for example in a namespace

   Class A
   Class B -superclass A
   B create b1

we have to destroy first object b1 (since this will call the destructor
methods of Class B and A as well), and then the classes A and B.
This is slightly more complicated with nested namespaces.
Therefore xotcl has to create a topological order from the set of
destroy candidates, call the destructors in this order and delete the
c-structures in a second round. Btw, a similar topological order is
used by the serializer.


best regards
-gustaf