Re: MT-safe exceptions?

Re: MT-safe exceptions?

[Mike Stump]

> From: Teemu Torma <tot@trema.com>
> To: egcs@cygnus.com
> Date: Mon, 08 Sep 1997 15:54:54 +0200

> Are there any plans to make C++ exceptions multi-thread safe?

Yes.  I will be doing this work in the coming months if no one beats
me to it.

> By looking the generated code, it does not look complicated task

No, not very complicated.  If someone wanted to try their hand at it,
I would be happy to help them out, just let me know.  Interface
changing in the compiler, reorganizing data into a structure, passing
a pointer to that structure around at runtime...

> I think the only major thing is to put all the variables into a
> structure, and call a routine in libgcc to get one, and possibly
> only once in each subroutine, not multiple times like now
> __get_dynamic_handler_chain gets called.

Right, that is an obvious optimization.  There are many such
optimizations.  The trick to to spend time on the ones that win the
most.

> Since it would require special libgcc,

Don't think of it as a special libgcc.  It will be the normal one,
it's just that the normal one might need some more support code in it
for EH.

> maybe an option -mt={pthread,<other target specific flavor>} that
> compile with needed flags (-D_REENTRANT in Solaris) and link with
> appropriate libraries.

Yes, this is yet another aspect of work that needs doing.

MT-safe exceptions?

[Teemu Torma]

    From:  mrs@wrs.com (Mike Stump)
    Date:  Mon, 8 Sep 1997 11:20:45 -0700

    > Since it would require special libgcc,
    
    Don't think of it as a special libgcc.  It will be the normal one,
    it's just that the normal one might need some more support code in it
    for EH.
    
Well, a libgcc compiled with threading enabled. 

This actually leads to another problem I ran a couple of days ago.
Now there is C++ code in libgcc, and because gcc has many options
that lead to binary incompability in C++ modules 
(vtable-thunks at least), it is not practical to use other than 
default options.  Other libraries like libstdc++ are easy to recompile 
with desired options, but libgcc is not.

One might think using multilibs for this purpose, but the number
of permutations will be quite high when combined to target
specific multilibs.

Teemu

Re: MT-safe exceptions?

[H.J. Lu]

> This actually leads to another problem I ran a couple of days ago.
> Now there is C++ code in libgcc, and because gcc has many options
> that lead to binary incompability in C++ modules 
> (vtable-thunks at least), it is not practical to use other than 
> default options.  Other libraries like libstdc++ are easy to recompile 
> with desired options, but libgcc is not.
> 
> One might think using multilibs for this purpose, but the number
> of permutations will be quite high when combined to target
> specific multilibs.
> 

I believe vtable-thunks should be not easily changable. It
should be either on or off. Otherwise, it will lead many
problems as we have seen in EH and libio.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: MT-safe exceptions?

[scott snyder]

>> Are there any plans to make C++ exceptions multi-thread safe?
>
>Yes.  I will be doing this work in the coming months if no one beats
>me to it.

I've been playing around with this a little, but i haven't finished
it yet.

I'm going on vacation in a couple days, though, and i don't know yet
if i'll have something working by then.  However, i'll try to send out
what i have before i leave, in case someone else wants to hack on it.

sss

MT-safe exceptions?

[Teemu Torma]

Are there any plans to make C++ exceptions multi-thread safe?  Now that
there are maybe working exceptions, it would be nice to use them in
multi-threaded programs.

By looking the generated code, it does not look complicated task (at
least for me, but on the other hand I have only vague idea what it
does).  The problem with current version (egcs-970907) is that it uses
global variables, instead of thread specific ones.  To make it work,
I think the only major thing is to put all the variables into a
structure, and call a routine in libgcc to get one, and possibly only
once in each subroutine, not multiple times like now
__get_dynamic_handler_chain gets called. 

Since it would require special libgcc, maybe an option
-mt={pthread,<other target specific flavor>} that compile with needed
flags (-D_REENTRANT in Solaris) and link with appropriate libraries.

Teemu