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