doc: fix spelling

Fix various typos and spelling mistakes in the documentation

PR-URL: https://github.com/libuv/libuv/pull/17
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

README.md

@@ -36,7 +36,7 @@ used by [Luvit](http://luvit.io/), [Julia](http://julialang.org/),
 ## Versioning
 
 Starting with version 1.0.0 libuv follows the [semantic versioning](http://semver.org/)
-scheme. The API change and backwards compatiblity rules are those indicated by
+scheme. The API change and backwards compatibility rules are those indicated by
 SemVer. libuv will keep a stable ABI across major releases.
 
 ## Community

docs/src/conf.py

@@ -261,7 +261,7 @@ man_pages = [
 #  dir menu entry, description, category)
 texinfo_documents = [
   ('index', 'libuv', u'libuv API documentation',
-   u'libuv contributors', 'libuv', 'Cross-platform asychronous I/O',
+   u'libuv contributors', 'libuv', 'Cross-platform asynchronous I/O',
    'Miscellaneous'),
 ]
 

docs/src/design.rst

@@ -8,7 +8,7 @@ libuv is cross-platform support library which was originally written for NodeJS.
 around the event-driven asynchronous I/O model.
 
 The library provides much more than simply abstraction over different I/O polling mechanisms:
-'handles' and 'streams' provde a high level abstraction for sockets and other entities;
+'handles' and 'streams' provide a high level abstraction for sockets and other entities;
 cross-platform file I/O and threading functionality is also provided, amongst other things.
 
 Here is a diagram illustrating the different parts that compose libuv and what subsystem they
@@ -42,7 +42,7 @@ operations, and it's meant to be tied to a single thread. One can run multiple e
 as long as each runs in a different thread. The libuv event loop (or any other API involving
 the loop or handles, for that matter) **is not thread-safe** except stated otherwise.
 
-The event loop follows the rather usual single threaded asynchronous I/O approah: all (network)
+The event loop follows the rather usual single threaded asynchronous I/O approach: all (network)
 I/O is performed on non-blocking sockets which are polled using the best mechanism available
 on the given platform: epoll on Linux, kqueue on OSX and other BSDs, event ports on SunOS and IOCP
 on Windows. As part of a loop iteration the loop will block waiting for I/O activity on sockets
@@ -104,7 +104,7 @@ stages of a loop iteration:
 
 #. Iteration ends. If the loop was run with ``UV_RUN_NOWAIT`` or ``UV_RUN_ONCE`` modes the
    iteration is ended and :c:func:`uv_run` will return. If the loop was run with ``UV_RUN_DEFAULT``
-   it will contionue from the start if it's asill *alive*, otherwise it will also end.
+   it will continue from the start if it's still *alive*, otherwise it will also end.
 
 
 .. important::

docs/src/dll.rst

@@ -4,7 +4,7 @@
 Shared library handling
 =======================
 
-libuv prodives cross platform utilities for loading shared libraries and
+libuv provides cross platform utilities for loading shared libraries and
 retrieving symbols from them, using the following API.
 
 

docs/src/fs.rst

@@ -258,7 +258,7 @@ API
             * ``UV_FS_SYMLINK_DIR``: indicates that `path` points to a directory.
 
             * ``UV_FS_SYMLINK_JUNCTION``: request that the symlink is created
-              using junktion points.
+              using junction points.
 
 .. c:function:: int uv_fs_readlink(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_fs_cb cb)
 

docs/src/fs_event.rst

@@ -95,7 +95,7 @@ API
 
     Get the path being monitored by the handle. The buffer must be preallocated
     by the user. Returns 0 on success or an error code < 0 in case of failure.
-    On sucess, `buf` will contain the path and `len` its length. If the buffer
+    On success, `buf` will contain the path and `len` its length. If the buffer
     is not big enough UV_ENOBUFS will be returned and len will be set to the
     required size.
 

docs/src/fs_poll.rst

@@ -62,7 +62,7 @@ API
 
     Get the path being monitored by the handle. The buffer must be preallocated
     by the user. Returns 0 on success or an error code < 0 in case of failure.
-    On sucess, `buf` will contain the path and `len` its length. If the buffer
+    On success, `buf` will contain the path and `len` its length. If the buffer
     is not big enough UV_ENOBUFS will be returned and len will be set to the
     required size.
 

docs/src/loop.rst

@@ -59,7 +59,7 @@ API
 .. c:function:: uv_loop_t* uv_default_loop(void)
 
     Returns the initialized default loop. It may return NULL in case of
-    allocation failture.
+    allocation failure.
 
 .. c:function:: int uv_run(uv_loop_t* loop, uv_run_mode mode)
 

docs/src/migration_010_100.rst

@@ -80,7 +80,7 @@ In libuv 0.10 Unix used a threadpool which defaulted to 4 threads, while Windows
 threads per process.
 
 In 1.0, we unified both implementations, so Windows now uses the same implementation Unix
-does. The threadppol size can be set by exporting the ``UV_THREADPOOL_SIZE`` environment
+does. The threadpool size can be set by exporting the ``UV_THREADPOOL_SIZE`` environment
 variable. See :c:ref:`threadpool`.
 
 
@@ -95,7 +95,7 @@ In libuv 0.10 the callback had to return a filled :c:type:`uv_buf_t` by value:
         return uv_buf_init(malloc(size), size);
     }
 
-In libuv 1.0 a pointer to a buffer is passed to the callbck, which the user
+In libuv 1.0 a pointer to a buffer is passed to the callback, which the user
 needs to fill:
 
 ::
@@ -200,7 +200,7 @@ for such function looked like this:
         ...
     }
 
-In libuv 1.0, `uv_read2_start` was removed, and the user needs to check if there are penging
+In libuv 1.0, `uv_read2_start` was removed, and the user needs to check if there are pending
 handles using :c:func:`uv_pipe_pending_count` and :c:func:`uv_pipe_pending_type` while in
 the read callback:
 
@@ -222,7 +222,7 @@ Extracting the file descriptor out of a handle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 While it wasn't supported by the API, users often accessed the libuv internals in
-order to get access to the file descript of a TCP handle, for example.
+order to get access to the file descriptor of a TCP handle, for example.
 
 ::
 

docs/src/misc.rst

@@ -1,10 +1,10 @@
 
 .. _misc:
 
-Miscelaneous utilities
+Miscellaneous utilities
 ======================
 
-This section contains miscelaneous functions that don't really belong in any
+This section contains miscellaneous functions that don't really belong in any
 other section.
 
 
@@ -186,11 +186,11 @@ API
 
 .. c:function:: int uv_ip4_name(const struct sockaddr_in* src, char* dst, size_t size)
 
-    Convert a binary structure containing an IPv4 addres to a string.
+    Convert a binary structure containing an IPv4 address to a string.
 
 .. c:function:: int uv_ip6_name(const struct sockaddr_in6* src, char* dst, size_t size)
 
-    Convert a binary structure containing an IPv6 addres to a string.
+    Convert a binary structure containing an IPv6 address to a string.
 
 .. c:function:: int uv_inet_ntop(int af, const void* src, char* dst, size_t size)
 .. c:function:: int uv_inet_pton(int af, const char* src, void* dst)

docs/src/pipe.rst

@@ -39,7 +39,7 @@ API
     Open an existing file descriptor or HANDLE as a pipe.
 
     .. note::
-        The user is responsible for setting the dile descriptor in non-blocking mode.
+        The user is responsible for setting the file descriptor in non-blocking mode.
 
 .. c:function:: int uv_pipe_bind(uv_pipe_t* handle, const char* name)
 

docs/src/stream.rst

@@ -62,7 +62,7 @@ Data types
 
     Callback called when a stream server has received an incoming connection.
     The user can accept the connection by calling :c:func:`uv_accept`.
-    `status` will de 0 in case of success, < 0 otherwise.
+    `status` will be 0 in case of success, < 0 otherwise.
 
 
 Public members
@@ -200,7 +200,7 @@ API
     When blocking mode is enabled all writes complete synchronously. The
     interface remains unchanged otherwise, e.g. completion or failure of the
     operation will still be reported through a callback which is made
-    asychronously.
+    asynchronously.
 
     .. warning::
         Relying too much on this API is not recommended. It is likely to change

docs/src/threadpool.rst

@@ -5,7 +5,7 @@ Thread pool work scheduling
 ===========================
 
 libuv provides a threadpool which can be used to run user code and get notified
-in the loop thread. This thread pool is internally used to run al filesystem
+in the loop thread. This thread pool is internally used to run all filesystem
 operations, as well as getaddrinfo and getnameinfo requests.
 
 Its default size is 4, but it can be changed at startup time by setting the