From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Johnson To: "Kevin D. Clark" Cc: Fred Forester , Pthreads Developers List Subject: Re: C++ cleanup handler execution Date: Thu, 06 Jan 2000 18:17:00 -0000 Message-id: References: <14453.4956.759854.712859@cabletron.com> X-SW-Source: 2000/msg00007.html 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 | +--------------------------+