[Xotcl] setExitHandler & threads

[Gustaf Neumann]

Scott Gargash schrieb:
>
>
> Unfortunately, the default behavior is not sufficient.  My example was 
> simplified from my real problem. In the real problem, I have 
> essentially a directed graph of objects that I serialize out upon 
> destruction.  Since the default behavior doesn't destroy objects in a 
> defined order, when the root object goes to serialize out, some nodes 
> that it needs to serialize may already be destroyed.  This is 
> undesireable.
>
one has to differantiate here more in detail. There is a defined order, 
otherwise xotcl would
horribly crash (referencing freed memory).
The shutdown happens in two rounds.

a) The first round is the "soft" destroy, were all  destroy methods are 
called. In this state calling destroy
    does not make a physical destruction, no memory is freed. First 
destroy is called for objects (making
    sure it is not called twice, then for all classes. The more detailed 
order depends on the hash tables and
    is therefore undefined.
b) after this, gobal xotcl-allocated variables and structures are freed.
    the second round is the phyiscal destroy, where memory is actually 
freed.
    first all objects not being classes and not having children are 
deleted until
    none of these exist. Then classes except ::xotcl::Object and 
::xotcl::Class
    are freed, that have no subclasses, no instances (for  metaclasses), 
and
    no children are deleted (in multiple rounds). finally 
::xotcl::Object and
    ::xotcl::Class are freed. Finally the global namespaces are freed 
and the
    destruction in is finished.

Before (a) and (b) the user exit handler is called. there a user is free 
to define his deletion logic.
>
>
> So I inserted my own exitHandler and that works in a single thread, 
> but when I have multiple threads, things get confused. 
>
You have not told us, what "confused" means (other than: "i get an 
error") since your
example works for me.

The shutown is differnt in the threaded case, since also tcl has and needs
different mechanisms here. in the single threaded case is only one exit 
handler,
in the multi threaded case is as well an thread exit handler (in xotcl, 
all threads
can have their own exit handler, defined by setExitHandler).

If you have multiple threads, and you want to control the order, in 
which the threads exit
(and in which their exit handlers are called), you have to do this on 
your own
as well (not using "exit", but your own shutdown command). Be aware of,
that tcl tries to shutdown your threads on exit as well.

>
> BTW, the failure was on WinXP.  Given that the behavior is different 
> on different platforms, it does seem like I've treaded into undefined 
> behavior.  Is there any way to wrangle it back into something defined?
>
i am not using windows. it is certainly possible that there is a 
different behavior
on thread exit, but first one has to understand, what the problem in 
your case is....

best regards
-gustaf neumann
>
>
> Scott
>