OSSP CVS Repository

ossp - Difference in ossp-pkg/pth/pth.pod versions 1.152 and 1.153
Not logged in
[Honeypot]  [Browse]  [Home]  [Login]  [Reports
[Search]  [Ticket]  [Timeline
  [History

ossp-pkg/pth/pth.pod 1.152 -> 1.153

--- 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

CVSTrac 2.0.1