OmniORB, Pentium GCC, Linux and race conditions

[Sai-Lai Lo]

Thanks for your message. 

1. We have not used the Pentium GCC (pgcc) compiler and is unsure about the
   quality of its support for exceptions and templates. The current version
   of gcc (2.7.2) *cannot* use optimisation and exception handling together.
   I don't know if pgcc is more advanced in this respect or if it just
   generates the wrong code if exception handling and optimisation are used
   together. Please fill us in with more info on pgcc, preferably by direct
   email in order to keep the volume of traffic on this mailing list
   reasonably low.

2. We are tracking the development of gcc and will make sure that
   omniORB2 will work with 2.8.0 when it comes out. In fact, we have tested
   our current development source with the latest development snapshot of
   gcc on Sparc Solaris.

3. An improved omnithread library will come with the next release. The
   omni_thread::wrapper has been changed to use a simpler mechanism.

4. The compiler warnings you reported come almost entirely from SUN's CFE
   IDL compiler frontend that we use in omniidl2. Some of these warnings
   can be removed by a general cleanup of SUN's CFE source. Some of them are
   warnings on the lex and yacc outputs that we do not want to touch.
   I'm confident that the warnings are quite harmless and hence are of low
   priority in fixing.

5. I'm not sure the problem you have in running "eg1" is the manifestation
   of a race condition. My gut feeling is that the compiler may be the one to
   blame. FYI, one of our development machine is a 7-processor Sun
   Enterprise Server and we regularly load test omniORB2 on it. It seems
   to me any race condition is more likely to show up on the big iron than
   a linux box :-)

6. I have received a number of requests for some documentation on how the
   code works. This will come some time in the future but don't hold your
   breath for it. In the mean time, it is best to start by looking at
   the stub code and works your way down. The header files in
   include/omniORB2 contains a lot more comments on the code than the
   source in lib/omniORB2.

Regards,

Sai-Lai Lo


>>>>> Amit Joshi writes:

> Hello,
> I have been playing with omniORB on Linux with the Pentium GCC (pgcc)
> compiler.
> - Everything compiles after changing the omni_thread::wrapper function
>   to a C++ binding, creating a ::wrapper2 function with C binding and
>   changing references for wrapper to wrapper2. 
> - There are however a plethora of warnings. Most seem to fall into two
>   categories: 
>     - switch statements without all the possible cases and no default:
>       case. Some of these, in "ast_expression.cc", I fixed.
>     - Some warning about initializations being re-ordered. Have to 
>       investigate this further. Any thought are welcome.
> - However the first example "eg1" fails with a segmentation. However if
>   I run the example in the debugger (gdb), let SIGUSR1 be handled with 
>   no interruptions, then it sometimes dies and sometime runs cleanly. It
>   seems to depend on how much I step through the code. This probably
>   means that there is a race condition where depending on which thread
>   manages to get to some point first. Seems to happen during the 
>   init routines. Any thoughts ? This does not occur with the regular
>   gcc compiler. The pgcc compiler produces faster code etc.

> My comments are: 
> - The code needs a lot of tightening up - the warnings are indicators.
> - There are some race conditions.
> - In order to understand the code I would need some internals
>   documentation.

> This is not to say that omniORB is bad or flame anybody or anything but
> some thoughts. I think that it is a good idea and a good product - I
> would not be spending time otherwise on it.