Re: C++ cleanup handler execution

[Ross Johnson <rpj at ise dot canberra dot edu dot au>]

On Thu, 6 Jan 2000, Kevin D. Clark wrote:

> Environment: VC++ 6.0 on a NT 4.x box with service pack 5.
>              Pthreads-win32 snapshot 1999-11-02
> 	     I am compiling a C++ program that uses C++ exceptions,
>              pthread_cancel(), pthread_cleanup_push(), and
>              pthread_cleanup_pop(). 
[snip]
> 	     
> So I went poking around in the code to see what was going on here.  I
> ran my code through the preprocessor and noticed that "__try" was
> being placed in my code.
> 
[snip]
> 
> Remember, I'm getting the SEH version of the cancel cleanup code.
> Now, it is my understanding that I shouldn't be using the SEH stuff in
> my C++ environment.
> 
> Assuming I'm right about this, I don't know if checking for _MSC_VER
> in the code is correct.  The Microsoft VC++ documentation that I have
> says that:
> 

Hi Kevin,

I agree that _MSC_VER needs to be changed to be more specific around
SEH related code.

Presumably something like the following should be used:

#if defined(_MSC_VER) && ! defined(__cplusplus)

or perhaps this might be tighter:

#if defined(_MSC_VER) && defined(_INC_EXCPT)

I'm also wondering if it's worth building the library only with C++
EH. That is, removing the SEH implementation, but not before
soliciting comments from the list. I've never actually built the
library using MSVC and C++ EH.

>         
> 2:  Are there any obvious caveats that I should look out for when
>     using the C++ cleanup code?  For example, while I was playing around
>     with this, I changed the definition of this:
> 
> #define pthread_cleanup_push( _rout, _arg ) \
>         { \
> 	    PThreadCleanup  cleanup((void (PT_STDCALL *)(void *))(_rout), \
> 				    (void *) (_arg) );
>     to be like this:
> 				    
> #define pthread_cleanup_push( _rout, _arg ) \
>         { \
> 	    PThreadCleanup  cleanup((void (*)(void *))(_rout), \
> 				    (void *) (_arg) );
> 				    
> because I was having a hard time compiling my code any other way.  Am
> I going to get bitten by any subtle calling convention bugs here?
> Should I have had to modify this code in the first place? (it compiles
> and runs fine on Solaris and Linux)
> 

PT_STDCALL is defined in the current version of pthread.h as:

#ifdef __MINGW32__
#define PT_STDCALL
#else
#define PT_STDCALL __stdcall
#endif

In the version that you have (snap-99-11-02) it's defined in
implement.h, which applications don't (must not) include. That was
an omission.

> 
> Thanks for any assistance you can provide!  And thanks for such a
> high-quality pthreads implementation!
> 

On behalf of all the contributors, thanks. And thank you for the
feedback and bug report. Your fix should be in the next snapshot.

I'm in the process of automating the build/test cycle so that I can
easily test both library and applications in all of the following
environments and cross-environments.

Eg.
	   Applications | SEH | C++ | G++ |  C  | GCC |
	Library		|     |     |     |     |     |
	----------------+-----+-----+-----+-----+-----+
	SEH		|  X  |  X  |  X  |  X  |  X  |
	----------------+-----+-----+-----+-----+-----+
	C++ (MSC)	|  X  |  X  |  X  |  X  |  X  |
	----------------+-----+-----+-----+-----+-----+
	G++ (GNU)	|  ?  |  ?  |  X  |  ?  |  X  |
	----------------+-----+-----+-----+-----+-----+

'?' indicates combinations that I'm not sure are doable.

Ross

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+