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

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

[Pinwu Xu]

>
>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

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

[erwin]

Pinwu Xu wrote:
> 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

I believe H.J. Lu wrote once that it is not wize to use libc5 with
threads. Correct me if i am wrong.

Erwin

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

[H.J. Lu]

> 
> Pinwu Xu wrote:
> > 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
> 
> I believe H.J. Lu wrote once that it is not wize to use libc5 with
> threads. Correct me if i am wrong.
> 

Yes. Don't use libc5 with MT. If you do, don't tell me it doesn't
work :-(.


-- 
H.J. Lu (hjl@gnu.org)

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

[H.J. Lu]

> 
> The point here was threadsafe exception handling with C++, not
> threadsafe programming in general. I don't know how much exception
> handling
> effects the C library but i am sure H.J. can tell you all about it.
> I also want to say the words "not wize" where my words and not those
> of H.J. maybe it is better to change them to "it is wizer to use glibc2"
> ?
> 

All I can say is please don't tell me that a threaded application,
in C or C++, with threaded-safe EH or without, doesn't work with
libc 5.4.x. Use glibc 2 if you want a working, reliable thread-safe
C library.

H.J.

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

[erwin]

The point here was threadsafe exception handling with C++, not
threadsafe programming in general. I don't know how much exception
handling
effects the C library but i am sure H.J. can tell you all about it.
I also want to say the words "not wize" where my words and not those
of H.J. maybe it is better to change them to "it is wizer to use glibc2"
?

Erwin


Kaz Kylheku wrote:
> 
> On Wednesday, March 25, 1998 6:16 AM, erwin [SMTP:erwin@htsa.hva.nl] wrote:
> > Pinwu Xu wrote:
> > > 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
> >
> > I believe H.J. Lu wrote once that it is not wize to use libc5 with
> > threads. Correct me if i am wrong.
> 
> I would hate to contradict H.J. Lu, but I wouldn't say that it
> is not ``wise''. It can certainly be done. Real projects exist which
> use libc5 with LinuxThreads (for example, the AOL multithreaded
> web server 2.2). http://www.aolserver.com/server/index.html .
> 
> Visit http://pauillac.inria.fr/~xleroy , follow the LinuxThreads link.
> 
> The thing to remember is that LinuxThreads does replace some
> libc functions that are not MT-safe. It provides mutex-protected
> malloc and friends, for instance; your application won't be
> calling the unsafe libc5 versions.
> 
> Xavier Leroy's FAQ warns that some versions of libc5 will
> not work. There is a section ``C. Issues releated to the
> C library'' that you should read.
> 
> The AOLserver 2.2 download page says that it was
> compiled with libc 5.3.12 (the newer 2.3 beta version
> has switched to glibc2). This is kind of funny, since
> the LinuxThreads FAQ recommends that you avoid
> 5.3.12. :)
> 
> Nevertheless, I'm quite happily using threads with libc5 on
> a multi-processor x86 box.  I haven't run into any problems
> so far. Which doesn't mean that problems aren't lurking in
> there. My code's interaction with the library is, however,
> limited to basic system calls and a bit of standard I/O.

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

[Kaz Kylheku]

On Wednesday, March 25, 1998 6:16 AM, erwin [SMTP:erwin@htsa.hva.nl] wrote:
> Pinwu Xu wrote:
> > 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
> 
> I believe H.J. Lu wrote once that it is not wize to use libc5 with
> threads. Correct me if i am wrong.

I would hate to contradict H.J. Lu, but I wouldn't say that it
is not ``wise''. It can certainly be done. Real projects exist which
use libc5 with LinuxThreads (for example, the AOL multithreaded
web server 2.2). http://www.aolserver.com/server/index.html . 

Visit http://pauillac.inria.fr/~xleroy , follow the LinuxThreads link.

The thing to remember is that LinuxThreads does replace some
libc functions that are not MT-safe. It provides mutex-protected
malloc and friends, for instance; your application won't be
calling the unsafe libc5 versions.

Xavier Leroy's FAQ warns that some versions of libc5 will
not work. There is a section ``C. Issues releated to the
C library'' that you should read.

The AOLserver 2.2 download page says that it was
compiled with libc 5.3.12 (the newer 2.3 beta version
has switched to glibc2). This is kind of funny, since
the LinuxThreads FAQ recommends that you avoid
5.3.12. :)

Nevertheless, I'm quite happily using threads with libc5 on
a multi-processor x86 box.  I haven't run into any problems
so far. Which doesn't mean that problems aren't lurking in
there. My code's interaction with the library is, however,
limited to basic system calls and a bit of standard I/O.