[ http://issues.apache.org/jira/browse/AXISCPP-629?page=all ] Fred Preston closed AXISCPP-629: --------------------------------
> Axis c does not compile on VisualStudio 7.0 or 7.1 > -------------------------------------------------- > > Key: AXISCPP-629 > URL: http://issues.apache.org/jira/browse/AXISCPP-629 > Project: Axis-C++ > Type: Bug > Components: Configuration > Versions: 1.5 Final > Environment: Windows XP, W2K3 > Reporter: Carsten Blecken > > See the following mail thread : > I couldn't find a JIRA to post the suggested fix against - by posted I just > meant to the axis-c-dev list (in fact this thread I believe) - should've > opened a JIRA I guess. If you get the (volatile) warnings on VC 7.1 then you > can probably just remove the volatile key word - I don't think 6 uses it > either. > Why are initialize_module/uninitialize_module extern "C" anyway? They are bad > function names to be exported by the shared library. Is this for the C > binding support? I'd suggest that if these aren't simply meant to be local > functions to Axis.cpp (which appears to be how they're used) then a better > structure would be: > static int initialize_module(int bServer) throw AxisException { /* existing > code */ } > static int uninitialize_module() throw AxisException { /* existing code */ } > extern "C" int axisc_initialize_module(int bServer) { > try { > return initialize_module(bServer); > } > catch (AxisException& e) { > /* log error */ > return AXIS_FAILURE; > } > catch (...) { > /* log error */ > return AXIS_FAILURE; > } > } > extern "C" int axisc_uninitialize_module() { > try { > retrurn uninitialize_module(); > } > catch (AxisException& e) { > /* log error */ > return AXIS_FAILURE; > } > catch (...) { > /* log error */ > return AXIS_FAILURE; > } > } > Cheers, > Tim > -- > IBM Tivoli Access Manager Development > Gold Coast Development Lab, Australia > +61-7-5552-4001 phone > +61-7-5571-0420 fax > "Carsten Blecken" <[EMAIL PROTECTED]> > 04/22/05 10:52 AM Please respond to > "Apache AXIS C Developers List" > To "Apache AXIS C Developers List" <[email protected]> > cc > Subject RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1) > > > Whoops you got me there. The mutex has to be created single threaded, which > doesn't apply here. If you say that you posted the code is there a JIRA > number > for it (other than 557). > > I had to add some explicit casts to get it compile on VC7.1 > static volatile long g_uModuleInitializing = 0; > static void start_initializing() > { > while (InterlockedIncrement((LONG*)&g_uModuleInitializing) != 1) { > InterlockedDecrement((LONG*)&g_uModuleInitializing); > } > } > static void done_initializing() > { > InterlockedDecrement((LONG*)&g_uModuleInitializing); > } > And we might want to move away from the /EHc compile flag: > [cc] > c:\eclipse301c\eclipse\workspace\axisc_head\src\engine\Axis.cpp(463) > : warning C4297: 'initialize_module' : function assumed not to throw an > excepti > on but does > [cc] The function is extern "C" and /EHc was specified > [cc] > c:\eclipse301c\eclipse\workspace\axisc_head\src\engine\Axis.cpp(463) > : warning C4297: 'initialize_module' : function assumed not to throw an > excepti > on but does > [cc] The function is extern "C" and /EHc was specified > [cc] > c:\eclipse301c\eclipse\workspace\axisc_head\src\engine\Axis.cpp(498) > : warning C4297: 'uninitialize_module' : function assumed not to throw an > excep > tion but does > [cc] The function is extern "C" and /EHc was specified > [cc] > c:\eclipse301c\eclipse\workspace\axisc_head\src\engine\Axis.cpp(498) > : warning C4297: 'uninitialize_module' : function assumed not to throw an > excep > tion but does > Carsten > > -----Original Message----- > From: Tim Bartley [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 21, 2005 5:05 PM > To: Apache AXIS C Developers List > Subject: RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1) > The purpose of the code is to avoid the (very small) risk of multiple threads > racing to initialise. > Two threads racing through the code below can both simultaneously pass the > "if (NULL == hMutex)" test - both create separate mutexes - and both > successfully lock it - then crash horribly while they race through the > initialization code. > I have already posted the code that should compile on both VC6 and VC7 - has > no body applied this to the tree yet? > Here is the modified code: > static volatile long g_uModuleInitializing = 0; > static void start_initializing() > { > while (InterlockedIncrement(&g_uModuleInitializing) != 1) { > InterlockedDecrement(&g_uModuleInitializing); > } > } > static void done_initializing() > { > InterlockedDecrement(&g_uModuleInitializing); > } > or maybe this has been applied but doesn't compile because of the > volatile/non-volatile mismatch between VC6 and VC7? I haven't seen the latest > CVS source. > Cheers, > Tim > -- > IBM Tivoli Access Manager Development > Gold Coast Development Lab, Australia > +61-7-5552-4001 phone > +61-7-5571-0420 fax > "Carsten Blecken" <[EMAIL PROTECTED]> > 04/22/05 09:58 AM > Please respond to > "Apache AXIS C Developers List" > > To "Apache AXIS C Developers List" <[email protected]> > cc > Subject RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1) > > > This seems to be the main reason why we can't compile on VC7. > I looked at the defs in winbase.h in 6 and 7 and the arguments have really > changed. Must be still void* in the end, since the call is implemented in > kernel32.dll. > Apart from defining ifdefs (i.e. WIN32_VC6 and WIN32_VC7) I can only > suggest to change the synchronization primitive. Why not using a mutex > like the UNIX code? > This seems to compile on both VC6 and VC7: > Axis.cpp(295) > #ifdef WIN32 > static HANDLE hMutex = NULL; > static void start_initializing() > { > if (NULL == hMutex) > hMutex = CreateMutex( NULL, FALSE, NULL); > WaitForSingleObject(hMutex, INFINITE); > } > static void done_initializing() > { > ReleaseMutex(hMutex); > } > #else > Carsten -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
