Re: Exposing gthreads, and making exceptions safe under cthreads

["Melissa O'Neill" <oneill at cs dot sfu dot ca>]

I wrote:
>> Given this situation, I propose that we expose the gthreads package
>> to the user, rather than keep it internal to the compiler sources.

Mike Stump writes:
> I don't know what you mean by this.  I think I am against this in all
> cases.  If you want to expose the user to a new interface, expose them
> to the standard posix interface, and implement that on top of mach and
> bundle that in the compiler.

The standard POSIX interface would be excellent, but POSIX provides a
pretty rich thread model and feature set. My point was that we could
provide a *minimal* wrapper for ``the local threads scheme'' so that
you don't have to be on a system that has POSIX threads support to have
a thread-safe gcc. On systems with POSIX threads, gthreads would be
POSIX threads, plain and simple (there would be no library, per se, just
a header file redirecting the gthreads names to POSIX names). But on
systems with cthreads, gthreads would be cthreads. And so on...

This is basically what is done now in the gthr-* headers -- but the work
is hoarded by the compiler, so the user has to face the problem of the
variety of operating system thread packages themselves.

>> 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.
>
> Yes, lets do that, and lets use the extension known as posix threads.

Are you volunteering to do the work?  Or do you know of an existing
POSIX wrapper for cthreads?

I certainly could alter my minimal wrapper for cthreads to use the POSIX
threads function names and argument types (it's just changing gthread*
to pthread* after all), but it wouldn't really be full POSIX threads.
And, using the posix names might even be a worse mistake, since I'd be
cluttering up the namespace so that people who *did* want to write a
true POSIX threads package would get name clashes.

>> 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 can't begin to describe all of my horror at this suggestion.

It would be wonderful if everyone had POSIX threads, but that isn't the
case right now. To me, this is just like the `libiberty' library -- it
provides a base-level of functionality. Users can and should use POSIX
threads when they either need more than that base level of functionality
or when they don't want to have code that'll run under whatever threads
scheme the operating system provides (including none at all).

I am not saying there should be a competing threads package for POSIX
threads with a competing interface. What I am saying is that it would
be cool to provide a wrapper for the local operating system threads package
that turns them into a minimal subset of POSIX threads (with gthread_*
rather than pthread_* names).

I don't see what is so horrific here. No one would be forced to use it,
no harm would be done.

     Melissa.