This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: "Generic" gthread model
>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
> On Aug 16, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
>> My analysis is that you had better make the symbol weak on platforms
>> that support it. Thread model "unknown" may be unusable in the manner
>> you want on platforms without weak support. This analysis is not
>> complete since I didn't cover all combinations of static and dynamic
>> nor all platforms of interest.
> Perhaps we should compile gthr-*.c into separate object files, and
> introduce some option to link in particular thread-support object
> files when given certain options in the command line?
That's what I've been thinking; that way we wouldn't have to worry about
bizarre configurations messing us up. We could also use weak references to
the gthr functions like we currently do to the pthread functions.
> Then, we could only link in a real thread library when the user gives
> -pthread in the command line, for example. Of course, if the system is
> configured with --enable-threads=pthread, we'd still use gthr-pthread.o
> by default, but there could be an option to link in with other thread
> models, or even with no thread model at all. If we do this, we'll no
> longer have to choose upfront whether to use pthreads or Solaris threads
> or no threads on Solaris, for example, and forgetting to --enable-threads
> would still make it possible to use thread models supported on a sytem,
> or even to plug in new thread models. An additional benefit is that this
> would obviate a set of multilibs for AIX, with the cost of additional
> function calls because of the extra indirection in thread primitives.
Sounds good to me.
[Jonathan: Sorry I didn't send this out last week.]
Jason