In some situations it is useful to know whether a given stream is
available for reading or writing. This information is normally not
-available and would have have to be remembered separately. Solaris
+available and would have to be remembered separately. Solaris
introduced a few functions to get this information from the stream
descriptor and these functions are also available in the GNU C library.
@comment stdio_ext.h
@comment GNU
-@deftypefun int __fwritaable (FILE *@var{stream})
+@deftypefun int __fwritable (FILE *@var{stream})
The @code{__fwritable} function determines whether the stream
@var{stream} was opened to allow writing. In this case the return value
is nonzero. For read-only streams the function returns zero.
This function is declared in @file{stdio_ext.h}.
@end deftypefun
-For a slightly different kind of problems there are two more functions.
+For slightly different kind of problems there are two more functions.
They provide even finer-grained information.
@comment stdio_ext.h
aware of a the possible complications. It is important to know about
these also if the program one writes never use threads since the design
and implementation of many stream functions is heavily influenced by the
-requierements added by multi-threaded programming.
+requirements added by multi-threaded programming.
The POSIX standard requires that by default the stream operations are
atomic. I.e., issueing two stream operations for the same stream in two
@comment POSIX
@deftypefun void flockfile (FILE *@var{stream})
The @code{flockfile} function acquires the internal locking object
-associated with the stream @var{stream}. This ensure that no other
+associated with the stream @var{stream}. This ensures that no other
thread can explicitly through @code{flockfile}/@code{ftrylockfile} or
implicit through a call of a stream function lock the stream. The
thread will block until the lock is acquired. An explicit call to
@comment stdio.h
@comment POSIX
@deftypefun int ftrylockfile (FILE *@var{stream})
-The@code{ftrylockfile} function tries to acquire the internal locking
+The @code{ftrylockfile} function tries to acquire the internal locking
object associated with the stream @var{stream} just like
@code{flockfile}. But unlike @code{flockfile} this function does not
block if the lock is not available. @code{ftrylockfile} returns zero if
is therefore always wrong to ignore the result of @code{ftrylockfile}.
And it makes no sense since otherwise one would use @code{flockfile}.
The result of code like that above is that either @code{funlockfile}
-tries to free a stream hasn't been locked by the current thread or it
+tries to free a stream that hasn't been locked by the current thread or it
frees the stream prematurely. The code should look like this:
@smallexample
@end smallexample
Now that we covered why it is necessary to have these locking it is
-necessary to talk about siuations when locking is unwanted and what can
+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
more. These variants of the functions behave just like the functions
with the name without the suffix except that they are not locking the
stream. Using these functions is very desirable since they are
-potentially very much faster. This is not only because the locking
+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 tradionally (before the
introduction of threads) were implemented as macros which are very fast
projects / platform / upstream / glibc.git / commitdiff