This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Exposing gthreads, and making exceptions safe under cthreads
- To: egcs at cygnus dot com, oneill at cs dot sfu dot ca
- Subject: Re: Exposing gthreads, and making exceptions safe under cthreads
- From: mrs at wrs dot com (Mike Stump)
- Date: Mon, 21 Sep 1998 20:26:51 -0700
> From: "Melissa O'Neill" <oneill@cs.sfu.ca>
> Date: Sat, 19 Sep 1998 23:55:28 -0700
> Given this situation, I propose that we expose the gthreads package
> to the user, rather than keep it internal to the compiler sources.
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.
> 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 extenion known as posix threads.
> 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.
> 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.
This is another way to solve it that I think would be ok. Or, do both.