The pthread_exit() in ThreadImpl::ThreadExecHandler doesn't do any harm because it is the last statement anyhow.
I wouldn't change the rest of the Thread methods. qSome thread may use Thread::exit() as a sort of an "emergency" stop if it cannot do a return from it's "run()" method. REgards, Werner David Sugar schrieb: > Do you think it is a defect in the core implementation of pthread_exit() > itself? That ThreadImpl should never call it? You are correct that > with a simple return, it will fall out. One possibility would be to > have a setjump/longjump in the trampoline function itself, and then have > a Thread "::exit" method which always longjump back to the ThreadImpl > function, and have that then just return for those cases where a thread > "exit" at a deeper routine needs to be forced.... > > Werner Dittmann wrote: >> 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 <SNIP --- SNAP> >> 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 >> >> >> _______________________________________________ >> Ccrtp-devel mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/ccrtp-devel _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
