This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Exposing gthreads, and making exceptions safe under cthreads


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]