Re: [omniORB] Re: Exception Handling is thread safe?

["Pinwu Xu" <pinwu_xu at hotmail dot com>]

>
>1. egcs 1.0.2 or gcc-2.8.1 *does not* have thread safe exceptions.
>   However, on x86 linux and other platforms that use PC range table >   
to handle exception. The generated code works most of the time  
>   unless you are so unlucky to have a thread-switch in a small      >   
critical region (a few
>   tens of instructions) *and* the new thread also throws an 
>   exception. 

>   The same cannot be said for platforms that use setjmp/longjmp to 
>   handle exception. On these platforms, multithread eh just doesn't 
>   work.
>

This explains why I could run most of the examples from omniORB. ;-)


>2. The current development snapshots *does* have thread safe 
>   exceptions.
>
>   However, there is a bug in the generated code which causes 
>   omniORB2 programs to hang (actually the bug causes it to call a 
>   destructor infinite times).
>   
>   I did some investigation yesterday and have isolated the problem 
>   into a small test case. The bug has been reported to egcs-bugs. I 
>   hope it will be fixed soon.
>
>   The workaround is simple. I could release a patch to omniidl2 to
>   generate the workaround code. However, I'm reluctant to do so at 
>   the moment because the same compiler bug may hit other parts of 
>   the code and may be much harder to track down.
>
>   For those who are interested, the following is the test case that 
>   shows the compiler bug. The bug causes eg3_{impl,clt} to hang.
>
The eg3_impl hang seems to be just what I got, as I installed 
egcs-1.0.2 (w/o the MT-eh patch) on a 486, libc5.4.44, recompiled
omniORB2 2.5.0. 

This situation is a little better than that with OmniBroker 2.0.3,
in which the test aborts if using C++ server.

Later.

Pinwu

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com