Re: More fallout from global.cc namespace changes

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

>> The following fixes by, declaring in __gnu_cxx is stl_threads.h. An
>> alternative is to revert part of the change and define these in namespace
>> std in globals.cc, as before.

> It would be nice to keep all implementation bits in globals.cc out of
> namespace std.

> You'll need to bump the date on the stl_threads.h copyright notice.  You
> could explicitly qualify the __gnu_cxx bits, or inject the names for
> struct _STL_mutex_lock only, instead of a global injection in this
> include file.

> Loren? This looks like the only remaining damage on BSD, correct? Thinks
> look ok on your testruns, threads excepted.

For the record, this issue is orthogonal to BSD (which supports static
mutex init).  POSIX threads, and thus the gthr abstraction layer,
allows either or both mutex-init-styles to be supported.  The BSD
tester, ref5, has been failing threading tests for a while (fixed in
today's report).

I am unsure that I'm happy with Danny's patch as committed (sorry, I
*never* read list traffic on weekends ;-).  I am happy with it, if the
related patch set will never move to the 3.2 branch and/or we
explicitly document an issue for any port supporting threads without
support for a static init mutex.  I am somewhat concerned at any name
change related to this mutex since code compiled before the name
change will silently not share the same mutex with code compiled after
it.  I.e.  effectively different locking protocols will be in affect
thus allowing for memory corruption if there is any contention on the
locked item.

Regards,
Loren