RFC: "Generic" gthread model

[Jonathan Larmour]

Hi Loren,

Thanks for the reply.

Loren James Rittle wrote:
> 
> In article < 3B7AE933.734E6AB4@redhat.com > you write:
> 
> > So opinions? Or if it's that good straight away ;), can someone check it
> > in?
> 
> I like this line of work.  However, IMHO it is not yet ready for
> check-in on the mainline.
> 
> > 2001-08-15  Jonathan Larmour  <jlarmour@redhat.com>
> >
> >       * Makefile.in (LIB2ADDEH): Build gthr-unknown.c.
> 
> Just an observation since it affects when we could make this change:
> This is an ABI change/addition for libgcc.

It is an addition in the sense that once in an official release, it would
need to be supported, but that doesn't make a difference to when the change
is made since it is irrelevant if unused, surely?

> Also, in keeping with other gthr implementations, shouldn't
> gthr-unknown.c only be included in libgcc when no other
> header-provided gthr implementation was encoded into the various gcc
> libraries that use the gthr abstration layer?

You mean the .c file should only be built when actually used? That wouldn't
be possible directly in the Makefile without GNU make-isms I think. I could
add some extra conditions to configure.in at the point gthr-default is made
to AC_SUBST an extra EXTRAEHOBJS variable for the makefile, containing
"$(srcdir)/gthr-unknown.c". Okay?

> Related issue: since libgcc no longer uses the gthr abstractions,
> might it be better to put the implementation object file
> (i.e. gthr-unknown.o) into the actual gcc libraries that requires it
> when unknown is the selected model?

As you say, libgcc _does_ still use gthr :-).
 
> How is overriding of symbols in libgcc suppose to work?  Does your
> answer change when you consider that libgcc is not always a static
> library anymore? (i.e. I think I see how it works when libgcc is
> static by library ordering, but not in other cases.)

The runtime must ensure that the (dynamic) linker will not get as far as
resolving the symbols from the libgcc. This could mean the crt0 (or
equivalent) will do this, or it may mean that the symbols get defined in
the C library when the thread implementation is used. I thought the dynamic
linker still preserved the search order? And libgcc is generally linked
last of all.

> >       * configure.in: Default to new "unknown" thread model if
> >       --enable-threads is used but no model is provided by the target.
> 
> When the user asks for thread support without stating what he wants,
> why is "unknown" (which, by default, maps to the equivalent of
> "single") better than a default of "single"?

Because that's not thread support, and the user has asked for thread
support :).

> It has already been
> decided (by three random gcc hackers on the public list) that a
> default thread model of "single" leads to confusion when the user
> explicitly provided --enable-threads yet the port has no support
> configured in config.gcc.

This change allows a runtime to provide that support after the fact. Or
perhaps not even the runtime - the user could (think user threads here). So
while previously GCC effectively didn't do what the user wanted (provide
thread support), we can now tell users: GCC doesn't support your thread
model, so that means you have to include that support in your application
or OS and plug it in to the API. It converts a situation where the user is
helpless unless they change GCC, to one where they can do the right thing
themselves.

One thing I had thought about was whether to make the functions weak. I
decided against this because I think that if any are to be overridden, they
all should be. But if anyone thinks otherwise...

>  I suppose the built gcc will now report
> "unknown" instead of "single", but making this situation an
> configure-time error seems better.

I agree reporting "unknown" as the thread model will probably make things a
bit clearer to users. But for the reasons above I think a hard error may be
a bit harsh. Anyway, that is not the purpose of this change :).

> >       * gthr.h: Document new __GTHREAD_MUTEX_DESTROY_FUNCTION
> >       interface.
> 
> If needed, then looks OK as long as every place in every gcc library
> using gthr is updated... ;-)

All uses of mutexes in libgcc are statics. I will deal with libstdc++ (is
it considered part of gcc? I consider it a separate project) separately, as
I mentioned in the original mail, once this is approved so that it's not
being written to a different interface.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine