Re: multithreaded EH is still broken on Linux/Alpha and other platforms

[hjl at lucon dot org (H.J. Lu)]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
>  >> >>>>> Jason Merrill writes:
>  >> 
>  >> >>>>> H J Lu <hjl@lucon.org> writes:
>  >> >> The Linux/x86 EH bug has nothing to do with thread.
>  >> 
>  >> > No, it has to do with you forgetting to define the copy constructor.
> 
>  > The bug is in /omniORB-980827. Here is the patch. I don't know why
> 
>  > static omni_thread::init_t omni_thread_init;
> 
>  > is in the header file.
> 
> So that anything that #includes the header is guaranteed that the
> thread stuff will have been initialized.  This is a common C++ idiom; it's
> even used by many iostream implementaitons.
> 

Well, it depends on what omni_thread_init does. I don't think that
particular omni_thread_init is designed for having more than one
copies or in any random files.


>  > It seems ok for compiler to generate
> 
>  > static omni_thread::init_t omni_thread_init;
> 
>  > for each source file which includes that header file.
> 
> I don't understand you.  Your patch just moves the line from the header
> into the .cc files, which is unmaintainable.  Why is it useful?
> 

Well, that particular .cc file I moved omni_thread_init into will
be linked in by every program which uses omni_thread.

If you take a closer look at the files I moved omni_thread_init into,
and try it on both Linux/x86 and Linux/alpha, you may understand it.

Strangely enough, egcs 1.1 only generates one copy of omni_thread_init
on Linux/x86 and it happens to be for that particular .cc file where I
moved omni_thread_init into. However, on Linux/alpha, omni_thread_init
is generated for every .cc file where the header file defining
omni_thread_init is included. That is one reason why it works on x86.
I think it may be an egcs bug. But I don't have the time to dig into.


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