The whole threads thing (was Re: [RFA] AIX thread support)

Phil Edwards pedwards@disaster.jaj.com
Thu Oct 12 14:01:00 GMT 2000


On Thu, Oct 12, 2000 at 01:30:34PM -0700, Benjamin Kosnik wrote:
> should be:
> 
> >     case "$target_thread_file" in  
> >       no | none | single)
> >         THREADH=threads-no.h
> >         ;;
> >       posix | pthreads | aix)
> >         THREADH=threads-posix.h

Wouldn't supporting that kind of "synonym" be the same as accepting the patch
anyhow?  Or was that just intended as an example of good, er, patchmanship?

(I agree that if we're using POSIX threads, we should /say/ that we're
using POSIX threads.  One of my long-term goals is to do the Solaris
native threads.)

This raises a problem that I've been tackling since yesterday.  Using
threads=no causes many many problems in libio, and in the sections of
src and bits that #include headers from libio.  A bunch of the locking
mechanisms assume that things are already in place.  With no thread support,
all of that fails.

Using threads=posix, I've gotten pretty far.  Giving the same Linux-based
macros that glibc assumes gets me as far as:

    ../../../../unified/libstdc++-v3/libio/genops.c:35:
    `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' undeclared here (not in a
    function)
    gmake[3]: *** [genops.lo] Error 1

And here I have to stop:  the _NP suffix on pthreads stuff indicates a
Non Portable extension.  I'm not certain what would be a good solution.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


More information about the Libstdc++ mailing list