[prev in list] [next in list] [prev in thread] [next in thread]
List: omniorb-list
Subject: [omniORB] omni_thread::join()
From: "Renzo Tomaselli" <renzo.tomaselli () tecnotp ! it>
Date: 1999-11-25 15:13:05
[Download RAW message or body]
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
---------------------------------------------------------------------------
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
---------------------------------------------------------------------------
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<META content="MSHTML 5.00.2014.210" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Hi,</FONT></DIV>
<DIV><FONT size=2> 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).</FONT></DIV>
<DIV><FONT size=2>The same sequence works well in any other context, e.g. from
normal methods.</FONT></DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2>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).</FONT></DIV>
<DIV><FONT size=2>Any idea ?</FONT></DIV>
<DIV><FONT
size=2> & \
nbsp; &nb \
sp; \
Renzo Tomaselli
<BR>---------------------------------------------------------------------------<BR>TecnoTP \
s.n.c. Special Information System Design<BR>Maso Pelauchi I38050 Ronchi
Valsugana, Trento TN ITALY<BR>Tel. +39 0461
773164 Fax. +39 0461 771514<BR>e-mail: <A
href="mailto:renzo.tomaselli@tecnotp.it">renzo.tomaselli@tecnotp.it</A>
<BR>---------------------------------------------------------------------------</FONT></DIV></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic