Re: Update of threading documentation in chapter 23

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

In article <flvghtnmry.fsf@jambon.cmla.ens-cachan.fr>,
Gabriel Dos Reis <gdr@codesourcery.com> writes:

> Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> |    <p><em>However, please ignore all discussions about the user-level
> |       configuration of the lock implementation inside the STL
> |       container-memory allocator on those pages.  For the sake of this
> |       discussion, libstdc++-v3 configures the SGI STL implementation,
> |       not you.  This is quite different from how gcc pre-3.0 worked.
> |       In particular, past advice was for people using g++ to
> |       explicitly define _PTHREADS or other macros or port-specific
> |       options on the [compilation]
> |       command line to get a thread-safe STL.  This is
> |       no longer required for any port and should no longer be done
> |       unless you really know what you are doing and assume all
> |       responsibility.</em>

> Well, we should then take the opportunity to document g++ command line
> options (-pthreads or -pthread, ...) needed to activate MT in the
> library and linking process.

Agreed, however, I will add that information to an update of chapter
17 (threading issues regarding the entire library not just
containers).

Also, I will correct the misnomer before I commit chapter 23 changes
(see the inline bracketed addition).  As you observed, it is not
exactly true that port-specific options are no longer required.

While it is true that compilation no longer requires special flags,
linking might still require the correct library and/or port-specific
flags to be provided unless weak symbols are supported.  In that case,
those libraries and flags are usually only required when the final
application is itself multithreaded.

Regards,
Loren