From aa2a8516ce528253bf241f1730876c904823e469 Mon Sep 17 00:00:00 2001
From: Phil Edwards
Date: Wed, 17 Oct 2001 18:14:58 +0000
Subject: [PATCH] howto.html: Remove 1999 links (and explain why).
2001-10-17 Phil Edwards
* docs/html/17_intro/howto.html: Remove 1999 links (and explain
why). Add link to recent message.
* docs/html/faq/index.html (5.6): Reformat text only; fixup
markup.
* docs/html/faq/index.txt: Regenerate.
From-SVN: r46321
---
libstdc++-v3/ChangeLog | 8 +++
libstdc++-v3/docs/html/17_intro/howto.html | 52 +++++-----------
libstdc++-v3/docs/html/faq/index.html | 71 +++++++++++-----------
libstdc++-v3/docs/html/faq/index.txt | 52 ++++++++++++----
4 files changed, 97 insertions(+), 86 deletions(-)
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 808d1f07420..32f6c21208a 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,11 @@
+2001-10-17 Phil Edwards
+
+ * docs/html/17_intro/howto.html: Remove 1999 links (and explain
+ why). Add link to recent message.
+ * docs/html/faq/index.html (5.6): Reformat text only; fixup
+ markup.
+ * docs/html/faq/index.txt: Regenerate.
+
2001-10-12 Loren J. Rittle
* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html
index d7ca3f3f274..69d9886887f 100644
--- a/libstdc++-v3/docs/html/17_intro/howto.html
+++ b/libstdc++-v3/docs/html/17_intro/howto.html
@@ -67,7 +67,8 @@
means for a library (not a general program). We currently use the
same
definition that SGI uses for their STL subset.
- Please see the many cautions given in HOWTOs on containers.
+ Please see the many cautions given in
+ HOWTOs on containers.
Here is another attempt at explaining the dangers of using the
STL with threading support without understanding some important
@@ -109,46 +110,21 @@
"Thread Next" to move down the thread. This farm is in
latest-to-oldest order.
-
- Here are discussions that took place before the current snapshot;
- they are still relevant and instructive. (Some of them may not work;
- as the drive containing some of the 1999 archives crashed, and nobody
- has had time to recover the backups.)
-
-
- - One way of preventing memory leaks by the old default memory
- allocator in multithreaded code is
- discussed here.
-
- This thread
- concerns strings.
-
- So does this
- one. This initial message also refers to another
- thread in the GCC mailing list...
-
- which is here,
- and goes on for some time. Ironically, the initial message
- in this thread also mentions another threading thread...
-
- beginning here,
- and talking about pthreads. (Note that a much more recent
- message from the first thread in this list notes that
- pthreads
- should not be used as a starting point for making
- libstdc++ threadsafe.)
-
- This
- message,
- this one,
- and this one
- are the tops of related threads (all within the same time
- period) discussing threading and the IO library. Much of it
- is dealing with the C library, but C++ is included as well.
+ POSIX-multithreaded STL code.
+
-
+ Here is an early analysis of why __USE_MALLOC should be disabled
+ for the 3.0 release of libstdc++.
+ (A large selection of links to older messages has been removed; many
+ of the messages from 1999 were lost in a disk crash, and the few
+ people with access to the backup tapes have been too swamped with work
+ to restore them. Many of the points have been superceded anyhow.)
This section will be updated as new and interesting issues come
to light.
diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html
index e0f31ceba3e..650a5ec700a 100644
--- a/libstdc++-v3/docs/html/faq/index.html
+++ b/libstdc++-v3/docs/html/faq/index.html
@@ -687,49 +687,46 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
When the system's libc is itself thread-safe, a non-generic
- implementation of atomicity.h exists for the architecture, and
- gcc itself reports a thread model other than single; libstdc++-v3
+ implementation of atomicity.h exists for the architecture, and gcc
+ itself reports a thread model other than single; libstdc++-v3
strives to be thread-safe. The user-code must guard against
- concurrent method calls which may access any particular
- library object's state. Typically, the application
- programmer may infer what object locks must be held based on
- the objects referenced in a method call. Without getting
- into great detail, here is an example which requires
- user-level locks:
-
+ concurrent method calls which may access any particular library
+ object's state. Typically, the application programmer may infer
+ what object locks must be held based on the objects referenced in
+ a method call. Without getting into great detail, here is an
+ example which requires user-level locks:
- library_class_a shared_object_a;
+ library_class_a shared_object_a;
- thread_main () {
- library_class_b *object_b = new library_class_b;
- shared_object_a.add_b (object_b); // must hold lock for shared_object_a
- shared_object_a.mutate (); // must hold lock for shared_object_a
- }
+ thread_main () {
+ library_class_b *object_b = new library_class_b;
+ shared_object_a.add_b (object_b); // must hold lock for shared_object_a
+ shared_object_a.mutate (); // must hold lock for shared_object_a
+ }
- // Multiple copies of thread_main() are started in independent threads.
-
- Under the assumption that object_a and object_b are never
- exposed to another thread, here is an example that should not
- require any user-level locks:
+ // Multiple copies of thread_main() are started in independent threads.
+ Under the assumption that object_a and object_b are never exposed to
+ another thread, here is an example that should not require any
+ user-level locks:
- thread_main () {
- library_class_a object_a;
- library_class_b *object_b = new library_class_b;
- object_a.add_b (object_b);
- object_a.mutate ();
- }
-
- All library objects are safe to use in a multithreaded
- program as long as each thread carefully locks out access by
- any other thread while it uses any object visible to another
- thread. This requirement includes both read and write access
- to objects; do not assume that two threads may read a shared
- standard container at the same time.
-
- See chapters 17,
- 23 and
- 27 for more information.
+ thread_main () {
+ library_class_a object_a;
+ library_class_b *object_b = new library_class_b;
+ object_a.add_b (object_b);
+ object_a.mutate ();
+ }
+
+ All library objects are safe to use in a multithreaded program as
+ long as each thread carefully locks out access by any other thread
+ while it uses any object visible to another thread. This requirement
+ includes both read and write access to objects; do not assume that
+ two threads may read a shared standard container at the same time.
+
+ See chapters 17 (library
+ introduction), 23
+ (containers), and 27 (I/O) for
+ more information.
diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt
index fcf84c8cd83..44c4748083c 100644
--- a/libstdc++-v3/docs/html/faq/index.txt
+++ b/libstdc++-v3/docs/html/faq/index.txt
@@ -548,15 +548,45 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
5.6 Is libstdc++-v3 thread-safe?
- Quick answer: no, as of 3.0, most of the library is not safe for
- multithreaded access. The string class is MT-safe.
-
- This is assuming that your idea of "multithreaded" is the same as
- ours... The general question of multithreading and libstdc++-v3 is
- addressed in the chapter-specific advice for [80]Library Introduction.
- Threadsafe containers are covered in more detail in [81]the Received
- Wisdom section on containers. Threading and I/O are discussed in
- [82]the I/O chapter.
+ When the system's libc is itself thread-safe, a non-generic
+ implementation of atomicity.h exists for the architecture, and gcc
+ itself reports a thread model other than single; libstdc++-v3 strives
+ to be thread-safe. The user-code must guard against concurrent method
+ calls which may access any particular library object's state.
+ Typically, the application programmer may infer what object locks must
+ be held based on the objects referenced in a method call. Without
+ getting into great detail, here is an example which requires
+ user-level locks:
+ library_class_a shared_object_a;
+
+ thread_main () {
+ library_class_b *object_b = new library_class_b;
+ shared_object_a.add_b (object_b); // must hold lock for shared_object_
+a
+ shared_object_a.mutate (); // must hold lock for shared_object_
+a
+ }
+
+ // Multiple copies of thread_main() are started in independent threads.
+
+ Under the assumption that object_a and object_b are never exposed to
+ another thread, here is an example that should not require any
+ user-level locks:
+ thread_main () {
+ library_class_a object_a;
+ library_class_b *object_b = new library_class_b;
+ object_a.add_b (object_b);
+ object_a.mutate ();
+ }
+
+ All library objects are safe to use in a multithreaded program as long
+ as each thread carefully locks out access by any other thread while it
+ uses any object visible to another thread. This requirement includes
+ both read and write access to objects; do not assume that two threads
+ may read a shared standard container at the same time.
+
+ See chapters [80]17 (library introduction), [81]23 (containers), and
+ [82]27 (I/O) for more information.
_________________________________________________________________
5.7 How do I get a copy of the ISO C++ Standard?
@@ -660,8 +690,8 @@ References
78. http://www.sgi.com/Technology/STL/
79. ../ext/howto.html
80. ../17_intro/howto.html#3
- 81. ../23_containers/howto.html
- 82. ../27_io/howto.html
+ 81. ../23_containers/howto.html#3
+ 82. ../27_io/howto.html#9
83. http://www.ansi.org/
84. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
85. http://www.iso.ch/
--
2.30.2