[reSIProcate] Transport threads hanging on shutdown

[Scott Godin]

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 at bridgewatersystems.com] 
Sent: Wednesday, February 09, 2005 11:15 AM
To: 'Scott Godin'; 'resiprocate-devel at list.sipfoundry.org'
Subject: RE: [reSIProcate] Transport threads hanging on shutdown
 
Hi Scott,
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.
 
Thanks,
Liz
-----Original Message-----
From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Tuesday, February 08, 2005 9:02 AM
To: 'Elizabeth Clark'; Scott Godin; 'resiprocate-devel at list.sipfoundry.org'
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 at bridgewatersystems.com] 
Sent: Tuesday, February 08, 2005 1:59 AM
To: 'Scott Godin'; 'resiprocate-devel at list.sipfoundry.org'
Subject: RE: [reSIProcate] Transport threads hanging on shutdown
 
Scott, 
This is the stack trace I am seeing:
 
~ThreadIf::join() <---- hang on pthread_join()
~UdpTransport()
~TransportSelector() 
 
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()
~TcpBaseTransport()
~TcpTransport()
~TransportSelector()
 
The problem occurs if TransportSelector::shutdown() is called to do a forced
shutdown prior to deleting stack objects.
 
Liz
-----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.
Liz
-----Original Message-----
From: Scott Godin [mailto:slgodin at icescape.com] 
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 at bridgewatersystems.com] 
Sent: Thursday, February 03, 2005 9:37 PM
To: 'resiprocate-devel at list.sipfoundry.org'
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();
 }
 
 
Elizabeth Clark                                 
Bridgewater Systems Corporation                
Phone :  (613) 591-9104 x2776
E-mail :  <mailto:elizabeth at bridgewatersystems.com>
mailto:elizabeth at bridgewatersystems.com
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050209/db985209/attachment.htm>