aboutsummaryrefslogtreecommitdiff
path: root/manual/stdio.texi
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>2001-08-12 16:44:22 +0000
committerUlrich Drepper <drepper@redhat.com>2001-08-12 16:44:22 +0000
commit3ca9e670b3dfeda650bf293429b11498d5d25d60 (patch)
treeb2dac54134b68c166c2856a6f9d0d23fb24b775a /manual/stdio.texi
parent5a5560f0f98a8c68dbe386055c487718d86aa321 (diff)
downloadglibc-3ca9e670b3dfeda650bf293429b11498d5d25d60.zip
glibc-3ca9e670b3dfeda650bf293429b11498d5d25d60.tar.gz
glibc-3ca9e670b3dfeda650bf293429b11498d5d25d60.tar.bz2
Fix typos and wording.
Diffstat (limited to 'manual/stdio.texi')
-rw-r--r--manual/stdio.texi17
1 files changed, 9 insertions, 8 deletions
diff --git a/manual/stdio.texi b/manual/stdio.texi
index 19a84a4..40f73f4 100644
--- a/manual/stdio.texi
+++ b/manual/stdio.texi
@@ -553,11 +553,11 @@ Now that we covered why it is necessary to have these locking it is
necessary to talk about situations when locking is unwanted and what can
be done. The locking operations (explicit or implicit) don't come for
free. Even if a lock is not taken the cost is not zero. The operations
-which have to be performed require memory operations which are save in
+which have to be performed require memory operations that are safe in
multi-processor environments. With the many local caches involved in
such systems this is quite costly. So it is best to avoid the locking
-completely if it is known that the code using the stream is never used
-in a context where more than one thread can use the stream at one time.
+completely if it is not needed -- because the code in question is never
+used in a context where two or more threads may use a stream at a time.
This can be determined most of the time for application code; for
library code which can be used in many contexts one should default to be
conservative and use locking.
@@ -566,15 +566,16 @@ There are two basic mechanisms to avoid locking. The first is to use
the @code{_unlocked} variants of the stream operations. The POSIX
standard defines quite a few of those and the GNU library adds a few
more. These variants of the functions behave just like the functions
-with the name without the suffix except that they are not locking the
+with the name without the suffix except that they do not lock the
stream. Using these functions is very desirable since they are
potentially much faster. This is not only because the locking
operation itself is avoided. More importantly, functions like
@code{putc} and @code{getc} are very simple and traditionally (before the
introduction of threads) were implemented as macros which are very fast
-if the buffer is not empty. With locking required these functions are
-now no macros anymore (the code generated would be too much). But these
-macros are still available with the same functionality under the new
+if the buffer is not empty. With the addition of locking requirements
+these functions are no longer implemented as macros since they would
+would expand to too much code.
+But these macros are still available with the same functionality under the new
names @code{putc_unlocked} and @code{getc_unlocked}. This possibly huge
difference of speed also suggests the use of the @code{_unlocked}
functions even if locking is required. The difference is that the
@@ -639,7 +640,7 @@ in @file{stdio_ext.h}.
This function is especially useful when program code has to be used
which is written without knowledge about the @code{_unlocked} functions
-(or if the programmer was to lazy to use them).
+(or if the programmer was too lazy to use them).
@node Streams and I18N
@section Streams in Internationalized Applications