[Ccrtp-devel] Bug when exiting the RTP send/receive thread

[Werner Dittmann]

during some tests using GNU ccRTP on a cygwin system installed on a
Windows XP SP2 I discovered some problems with the way ccRTP handles
threads. This also together with the implementation of Thread in the
common c++ library.

Ths usual way to stop a RTPSession is to delete the RTPSession
object. The destructor of RTPSession then shuts down the RTP thread:

~SingleThreadRTPSession()
{
    if (isRunning()) {
        disableStack(); Thread::join();
    }
}

Note: the destructor runs in the thread that calls delete.

The "run()" method of RTPSession dutifully checks the "isActive" flag
and exits the send/receive loop. After sending the BYE it calls
Thread::exit():

...
        }
        dispatchBYE("GNU ccRTP stack finishing.");
        Thread::exit();
...

Note: The above is called by the RTP send/receive thread.

At least in the said cygwin environment calling Thread::exit() is evil
:-) . The Thread::exit() just performs a pthread_exit() which
immediatly stops (at least in cygwin) the RTP send/receive
thread. Because of this "sudden death" the RTP send/receive thread is
not able to do the necessary housekeeping that will wakeup the other
thread waiting in join(). In other pthread implementations this might
work (it works on my Linux boxes). However, after calling
pthread_exit() the state and the thread's local variables are
undefined according to the pthread manual pages.

Porposal: remove the "Thread::exit()" and let the run() just
"return". This returns to the trampolin function
ThreadImpl::ThreadExecHandler which will close the thread that kicks
the join semaphore, then exits the thread. I've tested it an cygwin
and Linux, no problems.

Remark: it is not necessary that ThreadImpl::ThreadExecHandler call
pthread_exit() to terminate the thread, a simple return would be ok
here.

Regards,
Werner