[omniORB] omni_thread::join()
Renzo Tomaselli
renzo.tomaselli@tecnotp.it
Thu, 25 Nov 1999 16:13:05 +0100
This is a multi-part message in MIME format.
------=_NextPart_000_0013_01BF375F.F49F88E0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi,
I'm using OmniORB 2.8 on NT 4.0 and I actually found a problem about =
threads which is *not* an omnithread problem. I just wonder if anyone =
can help. What happens is that the usual sequence of terminating an =
undetached thread and then joining it doesn't work when the calling =
context is the desctructor of some static object in a dll, e.g. the =
common place where one is presumed to cleanup things before exiting =
(after a FreeLibrary call).
The same sequence works well in any other context, e.g. from normal =
methods.
To clarify, have a look at the ORB::NP_destroy() method in corbaorb.cc =
which cleans up OmniORB static things before exiting (there was a =
discussion thread on this issue sometime ago): if this method is called =
from within a dll static object destructor, the first invoked join() =
(the scavenger killer) waits forever in WaitForSingleObject. It seems =
that the exiting thread (which the thread list reports to be in =
_endthreadex) never get signalled so that the caller waits forever.
MSD doesn't report anything on this subject. Btw, cond. variable =
signal/wait works well across thread in any case: it's just the thread =
exiting which doesn't complete. Without a workaround, NP_destroy seems =
quite useless (I remember the original issue of stopping threads before =
Visual Basic unloads dlls).
Any idea ?
Renzo Tomaselli =20
-------------------------------------------------------------------------=
--
TecnoTP s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY
Tel. +39 0461 773164 Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it =20
-------------------------------------------------------------------------=
--
------=_NextPart_000_0013_01BF375F.F49F88E0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV><FONT size=3D2> I'm using OmniORB 2.8 on NT 4.0 =
and I=20
actually found a problem about threads which is *not* an omnithread =
problem. I=20
just wonder if anyone can help. What happens is that the usual sequence =
of=20
terminating an undetached thread and then joining it doesn't work when =
the=20
calling context is the desctructor of some static object in a dll, e.g. =
the=20
common place where one is presumed to cleanup things before exiting =
(after a=20
FreeLibrary call).</FONT></DIV>
<DIV><FONT size=3D2>The same sequence works well in any other context, =
e.g. from=20
normal methods.</FONT></DIV>
<DIV><FONT size=3D2>To clarify, have a look at the ORB::NP_destroy() =
method in=20
corbaorb.cc which cleans up OmniORB static things before exiting (there =
was a=20
discussion thread on this issue sometime ago): if this method is called =
from=20
within a dll static object destructor, the first invoked join() (the =
scavenger=20
killer) waits forever in WaitForSingleObject. It seems that the exiting =
thread=20
(which the thread list reports to be in _endthreadex) never get =
signalled so=20
that the caller waits forever.</FONT></DIV>
<DIV><FONT size=3D2>MSD doesn't report anything on this subject. Btw, =
cond.=20
variable signal/wait works well across thread in any case: it's just the =
thread=20
exiting which doesn't complete. Without a workaround, NP_destroy seems =
quite=20
useless (I remember the original issue of stopping threads before Visual =
Basic=20
unloads dlls).</FONT></DIV>
<DIV><FONT size=3D2>Any idea ?</FONT></DIV>
<DIV><FONT=20
size=3D2> &nbs=
p;  =
; =
=20
Renzo Tomaselli =20
<BR>---------------------------------------------------------------------=
------<BR>TecnoTP=20
s.n.c. Special Information System Design<BR>Maso Pelauchi I38050 Ronchi=20
Valsugana, Trento TN ITALY<BR>Tel. +39 0461=20
773164 Fax. +39 0461 771514<BR>e-mail: <A=20
href=3D"mailto:renzo.tomaselli@tecnotp.it">renzo.tomaselli@tecnotp.it</A>=
=20
<BR>---------------------------------------------------------------------=
------</FONT></DIV></BODY></HTML>
------=_NextPart_000_0013_01BF375F.F49F88E0--