Jonathan de Boyne Pollard wrote in a message to Phil Crown:

 JdBP>   I once had to maintain code that did this in a thread
 JdBP> procedure. 

 JdBP>      {
 JdBP>         MyClass thingy ;

 JdBP>         // ...

 JdBP>         DosEnterCritSec() ;
 JdBP>         WinPostMsg(MainWindow, WM_I_HAVE_FINISHED, 0, 0) ;
 JdBP>         WinDestroyMsgQueue(hmq) ;
 JdBP>         WinTerminate(hab) ;
 JdBP>         _endthread() ;
 JdBP>         DosExitCritSec() ;
 JdBP>      }
* * *
 JdBP>   It was murder to debug, not leastly because once a colleage 
 JdBP> (who had the debug kernel) had spotted the flaw I found it 
 JdBP> replicated all over the place in the application.

Still, the compiler should have been able to warn you about this sort of
construct if it knew that _endthread() was a function that never returns. 
Watcom, for example, can do this.  Of course, something as simple as
wrapping the call in a conditional would defeat any compiler warning:

   if(something)
      _endthread();

 JdBP>   Don't use _endthread() at the end of a thread procedure,
 JdBP> especially if you use C++.

This is a common misunderstanding of the documentation.  Since
_beginthread() is required, many people assume _endthread() is also
required.  Add this to the general lack of understand about what goes on
behind the curtain with C++ constructors and destructors, and this sort of
mistake is understandable.

 JdBP>   Don't use critical sections as a quick hack workaround (which 
 JdBP> is what I later found out that this was), because they bite.  
 JdBP> I'd put them right up there in the hall of infamy display case 
 JdBP> alongside Peter's   DosSuspendThread and DosKillThread.

This one is pretty infamous, I agree.
 
-- Mike


---