From 3a5ec70c0a7ebb365fdc886de8f6252750a74cd1 Mon Sep 17 00:00:00 2001
From: Chris Williams <chris@bingosnet.co.uk>
Date: Tue, 9 Mar 2010 11:47:59 +0000
Subject: [PATCH] Documentation fixes

---
 lib/IO/Async.pm |   34 +++++++++++++++++-----------------
 1 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/IO/Async.pm b/lib/IO/Async.pm
index fb8e1d7..015f9c8 100644
--- a/lib/IO/Async.pm
+++ b/lib/IO/Async.pm
@@ -61,9 +61,9 @@ C<IO::Async> - perform asynchronous filehandle IO and other operations
 
 This collection of modules allows programs to be written that perform
 asynchronous filehandle IO operations. A typical program using them would
-consist of a single subclass of C<IO::Async::Loop> to act as a container o
+consist of a single subclass of L<IO::Async::Loop> to act as a container of
 other objects, which perform the actual IO work required by the program. As
-as IO handles, the loop also supports timers and signal handlers, and
+well as IO handles, the loop also supports timers and signal handlers, and
 includes more higher-level functionallity built on top of these basic parts.
 
 Because there are a lot of classes in this collection, the following overview
@@ -80,31 +80,31 @@ The following sections describe particular types of Notifier.
 
 =head2 File Handle IO
 
-A L<IO::Async::Handle> object is a Notifier that represents a single IO handle
+An L<IO::Async::Handle> object is a Notifier that represents a single IO handle
 being managed. While in most cases it will represent a single filehandle, such
-as a socket (for example, an C<IO::Socket::INET> connection), it is possible
+as a socket (for example, an L<IO::Socket::INET> connection), it is possible
 to have separate reading and writing handles (most likely for a program's
 C<STDIN> and C<STDOUT> streams, or a pair of pipes connected to a child
 process).
 
-The L<IO::Async::Stream> class is a subclass of C<IO::Async::Handle> which
+The L<IO::Async::Stream> class is a subclass of L<IO::Async::Handle> which
 maintains internal incoming and outgoing data buffers. In this way, it
 implements bidirectional buffering of a byte stream, such as a TCP socket. The
 class automatically handles reading of incoming data into the incoming buffer,
 and writing of the outgoing buffer. Methods or callbacks are used to inform
 when new incoming data is available, or when the outgoing buffer is empty.
 
-The L<IO::Async::Listener> class is another subclass of C<IO::Async::Handle>
+The L<IO::Async::Listener> class is another subclass of L<IO::Async::Handle>
 which facilitates the use of C<listen()>-mode sockets. When a new connection
 is available on the socket it will C<accept()> it and pass the new client
 socket to its callback function.
 
 =head2 Timers
 
-A L<IO::Async::Timer::Countdown> object represents a counttime timer, which
+An L<IO::Async::Timer::Countdown> object represents a count time timer, which
 will invoke a callback after a given delay. It can be stopped and restarted.
 
-A L<IO::Async::Timer::Periodic> object invokes a callback at regular intervals
+An L<IO::Async::Timer::Periodic> object invokes a callback at regular intervals
 from its initial start time. It is reliable and will not drift due to the time
 taken to run the callback.
 
@@ -114,7 +114,7 @@ installed.
 
 =head2 Signals
 
-A L<IO::Async::Signal> object represents a POSIX signal, which will invoke a
+An L<IO::Async::Signal> object represents a POSIX signal, which will invoke a
 callback when the given signal is received by the process. Multiple objects
 watching the same signal can be used; they will all invoke in no particular
 order.
@@ -129,12 +129,12 @@ merge point, which is called when every subtask has completed.
 =head2 Loops
 
 The L<IO::Async::Loop> object class represents an abstract collection of
-C<IO::Async::Notifier> objects, and manages the actual filehandle IO
-watches, timers, signal handlers, and other functionallity. It performs all
+L<IO::Async::Notifier> objects, and manages the actual filehandle IO
+watchers, timers, signal handlers, and other functionallity. It performs all
 of the abstract collection management tasks, and leaves the actual OS
 interactions to a particular subclass for the purpose.
 
-L<IO::Async::Loop::Poll> uses an C<IO::Poll> object for this test.
+L<IO::Async::Loop::Poll> uses an L<IO::Poll> object for this test.
 
 L<IO::Async::Loop::Select> uses the C<select()> syscall.
 
@@ -143,13 +143,13 @@ as L<IO::Async::Loop::Glib> which acts as a proxy for the C<Glib::MainLoop> of
 a L<Glib>-based program, or L<IO::Async::Loop::Ppoll> which uses the
 L<IO::Ppoll> object to handle signals safely on Linux.
 
-As well as these general-purpose classes, the C<IO::Async::Loop> constructor
+As well as these general-purpose classes, the L<IO::Async::Loop> constructor
 also supports looking for OS-specific subclasses, in case a more efficient
 implementation exists for the specific OS it runs on.
 
 =head2 Child Processes
 
-The C<IO::Async::Loop> object provides a number of methods to facilitate the
+The L<IO::Async::Loop> object provides a number of methods to facilitate the
 running of child processes. C<spawn_child> is primarily a wrapper around the
 typical C<fork()>/C<exec()> style of starting child processes, C<open_child>
 builds on this to provide management of child process file handles and streams
@@ -183,7 +183,7 @@ function call arguments and return values.
 
 =head2 Networking
 
-The C<IO::Async::Loop> provides several methods for performing network-based
+The L<IO::Async::Loop> provides several methods for performing network-based
 tasks. Primarily, the C<connect> and C<listen> methods allow the creation of
 client or server network sockets. Additionally, the C<resolve> method allows
 the use of the system's name resolvers in an asynchronous way, to resolve
@@ -198,7 +198,7 @@ some of the potentially-useful parts or features currently missing are:
 
 =item *
 
-A C<IO::Async::Loop> subclass to perform integration with L<Event>. Consider
+An L<IO::Async::Loop> subclass to perform integration with L<Event>. Consider
 further ideas on Solaris' I<ports>, BSD's I<Kevents> and anything that might
 be useful on Win32.
 
@@ -208,7 +208,7 @@ A consideration on how to provide per-OS versions of the utility classes. For
 example, Win32 would probably need an extensively-different C<ChildManager>,
 or OSes may have specific ways to perform asynchronous name resolution
 operations better than the generic C<DetachedCode> approach. This should be
-easier to implement now that the C<IO::Async::Loop> magic constructor looks
+easier to implement now that the L<IO::Async::Loop> magic constructor looks
 for OS-specific subclasses first.
 
 =item *
-- 
1.7.0.1

