No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] setExitHandler & threads
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 16 Aug 2006 11:06:18 +0200
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
>
Date: Wed, 16 Aug 2006 11:06:18 +0200
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
>