deps: update libuv to 1.0.2

PR-URL: https://github.com/joyent/node/pull/8847
Reviewed-by: Trevor Norris <trev.norris@gmail.com>

12 files changed, 41 insertions, 21 deletions

diff --git a/deps/uv/docs/src/conf.py b/deps/uv/docs/src/conf.py
index 9ec9ec2c98..f614fc5b43 100644
--- a/deps/uv/docs/src/conf.py
+++ b/deps/uv/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'),
 ]
 
diff --git a/deps/uv/docs/src/design.rst b/deps/uv/docs/src/design.rst
index 803a421983..63141bedf5 100644
--- a/deps/uv/docs/src/design.rst
+++ b/deps/uv/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::
diff --git a/deps/uv/docs/src/dll.rst b/deps/uv/docs/src/dll.rst
index 3afa31f39d..3fb11e192d 100644
--- a/deps/uv/docs/src/dll.rst
+++ b/deps/uv/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.
 
 
diff --git a/deps/uv/docs/src/fs.rst b/deps/uv/docs/src/fs.rst
index 27d92d0b45..cd535f756f 100644
--- a/deps/uv/docs/src/fs.rst
+++ b/deps/uv/docs/src/fs.rst
@@ -191,6 +191,9 @@ API
 
     Equivalent to ``mkdtemp(3)``.
 
+    .. note::
+        The result can be found as a null terminated string at `req->path`.
+
 .. c:function:: int uv_fs_rmdir(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_fs_cb cb)
 
     Equivalent to ``rmdir(2)``.
@@ -258,7 +261,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)
 
diff --git a/deps/uv/docs/src/fs_event.rst b/deps/uv/docs/src/fs_event.rst
index eeb6bfbcb9..9bc9939fc2 100644
--- a/deps/uv/docs/src/fs_event.rst
+++ b/deps/uv/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.
 
diff --git a/deps/uv/docs/src/fs_poll.rst b/deps/uv/docs/src/fs_poll.rst
index 7459aac07b..df31053521 100644
--- a/deps/uv/docs/src/fs_poll.rst
+++ b/deps/uv/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.
 
diff --git a/deps/uv/docs/src/loop.rst b/deps/uv/docs/src/loop.rst
index c63ef7eb67..0a9e8a6086 100644
--- a/deps/uv/docs/src/loop.rst
+++ b/deps/uv/docs/src/loop.rst
@@ -50,6 +50,23 @@ API
 
     Initializes the given `uv_loop_t` structure.
 
+.. c:function:: int uv_loop_configure(uv_loop_t* loop, uv_loop_option option, ...)
+
+    Set additional loop options.  You should normally call this before the
+    first call to :c:func:`uv_run` unless mentioned otherwise.
+
+    Returns 0 on success or a UV_E* error code on failure.  Be prepared to
+    handle UV_ENOSYS; it means the loop option is not supported by the platform.
+
+    Supported options:
+
+    - UV_LOOP_BLOCK_SIGNAL: Block a signal when polling for new events.  The
+      second argument to :c:func:`uv_loop_configure` is the signal number.
+
+      This operation is currently only implemented for SIGPROF signals,
+      to suppress unnecessary wakeups when using a sampling profiler.
+      Requesting other signals will fail with UV_EINVAL.
+
 .. c:function:: int uv_loop_close(uv_loop_t* loop)
 
     Closes all internal loop resources. This function must only be called once
@@ -59,7 +76,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)
 
diff --git a/deps/uv/docs/src/migration_010_100.rst b/deps/uv/docs/src/migration_010_100.rst
index 83b3865567..bb6ac1a809 100644
--- a/deps/uv/docs/src/migration_010_100.rst
+++ b/deps/uv/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.
 
 ::
 
diff --git a/deps/uv/docs/src/misc.rst b/deps/uv/docs/src/misc.rst
index 1e1125ad6b..4b810fe084 100644
--- a/deps/uv/docs/src/misc.rst
+++ b/deps/uv/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)
diff --git a/deps/uv/docs/src/pipe.rst b/deps/uv/docs/src/pipe.rst
index 9a4a19340b..614bb2e3b1 100644
--- a/deps/uv/docs/src/pipe.rst
+++ b/deps/uv/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)
 
diff --git a/deps/uv/docs/src/stream.rst b/deps/uv/docs/src/stream.rst
index 44dccbe942..2c669cf041 100644
--- a/deps/uv/docs/src/stream.rst
+++ b/deps/uv/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
diff --git a/deps/uv/docs/src/threadpool.rst b/deps/uv/docs/src/threadpool.rst
index 875bb36aea..66ff53e230 100644
--- a/deps/uv/docs/src/threadpool.rst
+++ b/deps/uv/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