Exposing gthreads, and making exceptions safe under cthreads

Melissa O'Neill oneill@cs.sfu.ca
Sun Sep 20 06:39:00 GMT 1998

Currently, EGCS can't be compiled with the configure option --enable-threads
under systems that use cthreads (aka mach threads). The problem is that
there is no `gthr-mach.h' file for this platform (gthr-*.h files are
used in frame.c to manage exception information).

The underlying problem behind the lack of a gthr-mach.h file is that
it's difficult to write an interface to cthreads that is both efficient
and doesn't impact the user's ability to maintain their own thread-specific

Cthreads only provides *one* pointer for thread-specific data.  So, if
the application is using that pointer for its thread-specific data, any
library routines (such as those in libgcc) that want it for themselves
are out of luck.

Given this situation, I propose that we expose the gthreads package
to the user, rather than keep it internal to the compiler sources. If
both the user and the compiler are using the same extension to cthreads
to support multiple pieces of per-thread data, we can avoid the above
problems.  And, if we expose the gthreads interface on all platforms,
the change has the added benefit that anyone can write code for GCC using
the gthreads package and know it'll run on whatever threads scheme is
local to that architecture.

I have an implementation of the gthreads interface that's built on top
of cthreads that's ready to roll if we do this. If we don't do this, my
library is useless, since the user has to use cthreads and thus will
trample over that single per-thread pointer my library is relying on.

For gthreads on top of cthreads, I'd like to put the gthreads functions
into libgcc.a, since some functions can't be inlined and there's a
couple of static variables (although they could be put in a separate
library that's always linked). For other architectures, you just have
to install the current gthr-[whatever].h file as gthreads.h in the
include hierarchy, so it's hardly any work there, just a policy change.

Thoughts, opinions, etc. welcome...


P.S. It's also possible to provide a replacement cthreads header that
redirects cthreads names to gthreads names so that cthreads programs
can transparently use the gthreads library instead, with zero work on
the part of the user. But then you have to be sure that every module is
using this header and not the system one, so this idea has pros and
cons, whereas nothing above seems to have a downside.

More information about the Gcc mailing list