how to choose the threading system to use with gcj

Mon Nov 15 22:00:00 GMT 1999

Hello,
while studying the egcs/gcj sources I gained the impression that the choice
of the threading system is a configure option not only to the java-specific
run-time system libgcj, but also to some language-independent parts of
gcc's run-time. Specifically, I'm talking about libgcc2.c and the
various gthr- files in egcs/gcc. From looking at the sources, it seems 
that libgcc.a will contain inlined code from the various gthr files,
as many of the methods are declared static inline.
While this allows for some performance gain due to inlining if the
threading system is known when you configure your compiler, overall
this appears to be a very inflexible design. For one, I'm wondering
how it'll work in practice. If I download the next gcc RPM from 
Redhat/Cygnus, which version will they pick? Pthreads? no-threads? 
Solaris threads? DCE threads? Will there be four rpms?
Shouldn't this be a cmd-line switch to gcj? (Assuming that you 
compile multiple versions of libgcc.a and have gcj pick the right one?)
Secondly, it means that it'll be impossible to use libgcc's
run-time support code with thread packages other than those already
included in the gcc source tree. There's literally hundreds of thread
packages out there that are often tailored to a given application area.
gcc-compiled C++ or Java code will not work with them.
A straightforward solution to the second problem would be to provide 
a generic interface that is resolved not at compile-time, but at run-time.
A simple function pointer table, for instance.
Because of the (currently) small size of the gthread interface, this
should only be a few lines of code. If I did that, would there be
any obstacles in including that generic interface into the gcc source
code base?
How do other people feel about this issue? 
	- Godmar