--- pth.pod 2002/01/30 12:54:24 1.152
+++ pth.pod 2002/04/27 11:18:57 1.153
@@ -489,7 +489,7 @@
reentered before it returned. This is a great portability benefit,
because thread-safety can be achieved more easily than reentrance
possibility. Especially this means that under B<Pth> more existing
-third-party libraries can be used without side-effects than its the case
+third-party libraries can be used without side-effects than it's the case
for other threading systems.
=item B<o>
@@ -552,7 +552,7 @@
a thread never directly switches to another thread. A thread always
yields execution to the scheduler and the scheduler dispatches to the
next thread. So a freshly spawned thread has to be kept somewhere until
-the scheduler gets a chance to pick it up for scheduling. That is for
+the scheduler gets a chance to pick it up for scheduling. That is
what the B<NEW> queue is for.
The purpose of the B<DEAD> queue is to support thread joining. When a
@@ -573,8 +573,8 @@
=head1 APPLICATION PROGRAMMING INTERFACE (API)
In the following the B<Pth> I<Application Programming Interface> (API)
-is discussed in detail. With the knowledge given above, it should be
-now easy to understand how to program threads with this API. In good
+is discussed in detail. With the knowledge given above, it should now
+be easy to understand how to program threads with this API. In good
Unix tradition, B<Pth> functions use special return values (C<NULL>
in pointer context, C<FALSE> in boolean context and C<-1> in integer
context) to indicate an error condition and set (or pass through) the
@@ -609,7 +609,7 @@
terminate, kills the threading system and then terminates the process) or a
`C<pth_kill(); exit(0)>' (which immediately kills the threading system and
terminates the process). The pth_kill() return immediately with a return
-code of C<FALSE> if it is called not from within the main thread. Else
+code of C<FALSE> if it is not called from within the main thread. Else it
kills the threading system and returns C<TRUE>.
=item long B<pth_ctrl>(unsigned long I<query>, ...);
@@ -767,7 +767,7 @@
=back
-The following API functions exists to handle the attribute objects:
+The following API functions can be used to handle the attribute objects:
=over 4
@@ -839,8 +839,8 @@
=head2 Thread Control
-The following functions control the threading itself and form the main API of
-the B<Pth> library.
+The following functions control the threading itself and make up the main API
+of the B<Pth> library.
=over 4
@@ -928,7 +928,7 @@
is, not in C<PTH_STATE_NEW> or C<PTH_STATE_READY>) an error is reported.
The function usually returns C<TRUE> for success and only C<FALSE> (with
-C<errno> set to C<EINVAL>) if I<tid> specified and invalid or still not
+C<errno> set to C<EINVAL>) if I<tid> specified an invalid or still not
new or ready thread.
=item int B<pth_nap>(pth_time_t I<naptime>);
@@ -1002,7 +1002,7 @@
=head2 Utilities
-The following functions are utility functions.
+Utility functions.
=over 4
@@ -1302,7 +1302,7 @@
=head2 Thread Cleanups
-The following functions provide per-thread cleanup functions.
+Per-thread cleanup functions.
=over 4
@@ -1588,7 +1588,7 @@
This is a variant of the 4.3BSD usleep(3) function. It suspends the current
threads execution until I<usec> microseconds (= I<usec>*1/1000000 sec)
-elapsed. The thread is guaranteed to not awakened before this time, but
+elapsed. The thread is guaranteed to not wake up before this time, but
because of the non-preemptive scheduling nature of B<Pth>, it can be awakened
later, of course. The difference between usleep(3) and pth_usleep(3) is that
that pth_usleep(3) suspends only the execution of the current thread and not
@@ -1598,9 +1598,9 @@
This is a variant of the POSIX sleep(3) function. It suspends the current
threads execution until I<sec> seconds elapsed. The thread is guaranteed to
-not awakened before this time, but because of the non-preemptive scheduling
+not wake up before this time, but because of the non-preemptive scheduling
nature of B<Pth>, it can be awakened later, of course. The difference between
-sleep(3) and pth_sleep(3) is that that pth_sleep(3) suspends only the
+sleep(3) and pth_sleep(3) is that pth_sleep(3) suspends only the
execution of the current thread and not the whole process.
=item pid_t B<pth_waitpid>(pid_t I<pid>, int *I<status>, int I<options>);
@@ -1608,7 +1608,7 @@
This is a variant of the POSIX waitpid(2) function. It suspends the
current threads execution until I<status> information is available for a
terminated child process I<pid>. The difference between waitpid(2) and
-pth_waitpid(3) is that that pth_waitpid(3) suspends only the execution of the
+pth_waitpid(3) is that pth_waitpid(3) suspends only the execution of the
current thread and not the whole process. For more details about the
arguments and return code semantics see waitpid(2).
@@ -1617,7 +1617,7 @@
This is a variant of the POSIX system(3) function. It executes the
shell command I<cmd> with Bourne Shell (C<sh>) and suspends the current
threads execution until this command terminates. The difference between
-system(3) and pth_system(3) is that that pth_system(3) suspends only
+system(3) and pth_system(3) is that pth_system(3) suspends only
the execution of the current thread and not the whole process. For more
details about the arguments and return code semantics see system(3).
@@ -1644,7 +1644,7 @@
This is a variant of the 4.2BSD connect(2) function. It establishes a
connection on a socket I<s> to target specified in I<addr> and I<addrlen>.
-The difference between connect(2) and pth_connect(3) is that that
+The difference between connect(2) and pth_connect(3) is that
pth_connect(3) suspends only the execution of the current thread and not the
whole process. For more details about the arguments and return code semantics
see connect(2).
@@ -1655,7 +1655,7 @@
a socket by extracting the first connection request on the queue of pending
connections, creating a new socket with the same properties of I<s> and
allocates a new file descriptor for the socket (which is returned). The
-difference between accept(2) and pth_accept(3) is that that pth_accept(3)
+difference between accept(2) and pth_accept(3) is that pth_accept(3)
suspends only the execution of the current thread and not the whole process.
For more details about the arguments and return code semantics see accept(2).
@@ -1679,7 +1679,7 @@
This is a variant of the POSIX read(2) function. It reads up to I<nbytes>
bytes into I<buf> from file descriptor I<fd>. The difference between read(2)
-and pth_read(2) is that that pth_read(2) suspends execution of the current
+and pth_read(2) is that pth_read(2) suspends execution of the current
thread until the file descriptor is ready for reading. For more details about
the arguments and return code semantics see read(2).
@@ -1687,7 +1687,7 @@
This is a variant of the POSIX readv(2) function. It reads data from
file descriptor I<fd> into the first I<iovcnt> rows of the I<iov> vector. The
-difference between readv(2) and pth_readv(2) is that that pth_readv(2)
+difference between readv(2) and pth_readv(2) is that pth_readv(2)
suspends execution of the current thread until the file descriptor is ready for
reading. For more details about the arguments and return code semantics see
readv(2).
@@ -1696,7 +1696,7 @@
This is a variant of the POSIX write(2) function. It writes I<nbytes> bytes
from I<buf> to file descriptor I<fd>. The difference between write(2) and
-pth_write(2) is that that pth_write(2) suspends execution of the current
+pth_write(2) is that pth_write(2) suspends execution of the current
thread until the file descriptor is ready for writing. For more details about
the arguments and return code semantics see write(2).
@@ -1704,7 +1704,7 @@
This is a variant of the POSIX writev(2) function. It writes data to
file descriptor I<fd> from the first I<iovcnt> rows of the I<iov> vector. The
-difference between writev(2) and pth_writev(2) is that that pth_writev(2)
+difference between writev(2) and pth_writev(2) is that pth_writev(2)
suspends execution of the current thread until the file descriptor is ready for
reading. For more details about the arguments and return code semantics see
writev(2).
@@ -1735,7 +1735,7 @@
This is a variant of the SUSv2 recvfrom(2) function. It reads up to
I<nbytes> bytes into I<buf> from file descriptor I<fd> while using
I<flags> and I<from>/I<fromlen>. The difference between recvfrom(2) and
-pth_recvfrom(2) is that that pth_recvfrom(2) suspends execution of the
+pth_recvfrom(2) is that pth_recvfrom(2) suspends execution of the
current thread until the file descriptor is ready for reading. For more
details about the arguments and return code semantics see recvfrom(2).
@@ -1749,7 +1749,7 @@
This is a variant of the SUSv2 sendto(2) function. It writes I<nbytes>
bytes from I<buf> to file descriptor I<fd> while using I<flags> and
I<to>/I<tolen>. The difference between sendto(2) and pth_sendto(2) is
-that that pth_sendto(2) suspends execution of the current thread until
+that pth_sendto(2) suspends execution of the current thread until
the file descriptor is ready for writing. For more details about the
arguments and return code semantics see sendto(2).
@@ -1878,10 +1878,10 @@
=head2 Autoconf Build Environment (Advanced)
-The previous approach is simple but unflexible. First, to speed up
+The previous approach is simple but inflexible. First, to speed up
building, it would be nice to not expand the compiler and linker flags
every time the compiler is started. Second, it would be useful to
-also be able to build against an uninstalled B<Pth>, that is, against
+also be able to build against uninstalled B<Pth>, that is, against
a B<Pth> source tree which was just configured and built, but not
installed. Third, it would be also useful to allow checking of the
B<Pth> version to make sure it is at least a minimum required version.
@@ -2196,7 +2196,7 @@
entry point [see C<pth_tcb.h> and C<pth_pqueue.c> for details].
Most time critical code sections (especially the dispatcher and event
-manager) are speeded up by inlined functions (implemented as ANSI C
+manager) are speeded up by inline functions (implemented as ANSI C
pre-processor macros). Additionally any debugging code is I<completely>
removed from the source when not built with C<-DPTH_DEBUG> (see Autoconf
C<--enable-debug> option), i.e., not only stub functions remain [see
|
