[reSIProcate] Transport threads hanging on shutdown

[Elizabeth Clark]

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/9008fe21/attachment.htm>