I think all you can do after calling
shutdown is delete the stack anyway – since that was the way the code
used to work before the shutdown() changes, I just put it back. Since Jason F. made the shutdown changes –
I’ll let him comment on that one.
Thanks,
Scott
From: Elizabeth Clark
[mailto:elizabeth.clark@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 09, 2005
11:15 AM
To: 'Scott Godin';
'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate]
Transport threads hanging on shutdown
I've tested your fix and it's
working fine now. I just want to point one thing. If someone expects the
transport threads to shutdown when calling DialogUsageManager::forceShutdown or
SipStack::shutdown(), the threads won't shut down at that point; they are
shutdown when the transports are destroyed.
-----Original Message-----
From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx]
Sent: Tuesday, February 08, 2005
9:02 AM
To: 'Elizabeth Clark'; Scott
Godin; 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate]
Transport threads hanging on shutdown
Right... Ok - Looks like the shutdown
function that was recently added to UdpTransport and TcpBaseTransport was
mistakenly being called instead of ThreadIf::shutdown from the Udp/Tcp/DTls/Transports
destructors. I scoped out the shutdown call in the destructors so that
ThreadIf shutdown is called properly. This should fix the issue you are
seeing.
Thanks,
Scott
From: Elizabeth Clark
[mailto:elizabeth.clark@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, February 08, 2005
1:59 AM
To: 'Scott Godin';
'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate]
Transport threads hanging on shutdown
This is the stack trace I am seeing:
~ThreadIf::join() <---- hang on
pthread_join()
If you look at ~UdpTransport() you see
that shutdown() was called prior to join(), but it is
UdpTransport::shutdown() that gets called and it does not signal the
thread.
For TCP, the same problem occurs:
~ThreadIf::join() <---- hang on
pthread_join()
The problem occurs if
TransportSelector::shutdown() is called to do a forced shutdown prior to
deleting stack objects.
-----Original Message-----
From: Elizabeth Clark
Sent: Monday, February 07, 2005
1:09 PM
To: 'Scott Godin'; Elizabeth Clark
Subject: RE: [reSIProcate]
Transport threads hanging on shutdown
Nope, it's not working. It's calling the
the sub-classed shutdown. I believe that is correct polymorphic behavior
since shutdown() is virtual.
To explicitly call ThreadIf::shutdown,
from ~ThreadIf() the call should be written as ::shutdown(). This is an
alternative solution to the one I gave.
If I'm the only one to encounter this
problem, I have to think that the Sun compiler has made a different
interpretation than the others.
Thanks for looking into this.
-----Original Message-----
From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx]
Sent: Monday, February 07, 2005
12:20 PM
To: 'Elizabeth Clark'
Subject: RE: [reSIProcate]
Transport threads hanging on shutdown
Elizabeth,
I was just looking at the code - it seems
the threadIf shutdown is called from the ThreadIf destructor - so the thread
should die when the Transport is deleted. Is this not working?
Scott
From: Elizabeth Clark
[mailto:elizabeth.clark@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, February 03, 2005
9:37 PM
To: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: [reSIProcate] Transport
threads hanging on shutdown
When running the stack with transport threads (multiThreaded
=true), I find the transport threads are not being shutdown. The
Transport::shutdown() method hides ThreadIf::shutdown() so it never gets
called. I made this change which works.
Index: Transport.cxx
===================================================================
--- Transport.cxx (revision 3844)
+++ Transport.cxx (working copy)
@@ -62,6 +62,7 @@
{
// !jf! should use the fifo to pass this in
mShuttingDown = true;
+ ThreadIf::shutdown();
}
|