No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Object destruction on exit
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 03 Feb 2006 11:40:00 +0100
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
Date: Fri, 03 Feb 2006 11:40:00 +0100
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