When cleaning up after uv_fs_readdir(), it is important to
call uv_fs_req_cleanup() on the readdir request prior to calling
uv_fs_closedir(), because the latter frees memory that the
former needs in order to do its job.
PR-URL: https://github.com/libuv/libuv/pull/2497
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add an API for obtaining cryptographically strong random data from the
system PRNG.
Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>
Refs: https://github.com/libuv/libuv/pull/1055
PR-URL: https://github.com/libuv/libuv/pull/2347
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This commit contains a suggestion to hopefully improve the
documentation of uv_handle_t's member uv_loop_t.
PR-URL: https://github.com/libuv/libuv/pull/2446
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Continuing improvement of SIGWINCH from PR #2308.
Running SetWinEventHook without filtering for the specific PIDs has
significant impact on the performance of the entire system. This PR
changes the way SIGWINCH is handled.
The SetWinEventHook callback now signals a separate thread,
uv__tty_console_resize_watcher_thread. This thread calls
uv__tty_console_signal_resize() which checks if the console was actually
resized. The uv__tty_console_resize_watcher_thread makes sure to not to
call the uv__tty_console_signal_resize function more than 30 times per
second.
The SetWinEventHook will not be installed, if the PID of the
conhost.exe process that owns the console window cannot be
determinated. This can happen when a 32bit libuv app is running on a
64bit Windows.
For such cases PR #1408 is partially reverted - when tty reads
WINDOW_BUFFER_SIZE_EVENT, it will also trigger a call to
uv__tty_console_signal_resize(). This will also help when the app is
running under console emulators. Documentation was also updated to
reflect that.
Refs: https://github.com/microsoft/terminal/issues/1811
Refs: https://github.com/microsoft/terminal/issues/410
Refs: https://github.com/libuv/libuv/pull/2308
PR-URL: https://github.com/libuv/libuv/pull/2381
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Clarify the uv_buf_t isn't reused and the user is responsible for
freeing it in the recv/read callback.
Previously, this wasn't clear when reading only the docs for
uv_udp_recv_cb and uv_alloc_cb.
PR-URL: https://github.com/libuv/libuv/pull/2438
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
It resets a TCP connection by sending a RST packet. Due to some platform
inconsistencies, mixing of `uv_shutdown` and `uv_tcp_close_reset` calls
is not allowed.
Fixes: https://github.com/libuv/libuv/issues/1991
PR-URL: https://github.com/libuv/libuv/pull/2425
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reading and writing files using a memory file mapping can be
significantly faster on Windows.
PR-URL: https://github.com/libuv/libuv/pull/2295
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
app.info() was deprecated on Jan 4, 2017 (sphinx-doc/sphinx#3267),
and removed as of Sphinx 2.0.0. This commit removes the usage of
app.info().
PR-URL: https://github.com/libuv/libuv/pull/2265
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
PR-URL: https://github.com/libuv/libuv/pull/2221
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Add two new methods:
`uv_udp_connect()` to connect / disconnect an UDP handle.
`uv_udp_getpeername()` to get the remote peer address of a connected UDP
handle.
Modify `uv_udp_send()` and `uv_udp_try_send()` to accept a `NULL` `addr`
to send messages over an "UDP connection".
Refs: https://github.com/libuv/leps/pull/10
PR-URL: https://github.com/libuv/libuv/pull/1872
Backport-PR-URL: https://github.com/libuv/libuv/pull/2217
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit adds UV_MAXHOSTNAMESIZE for working with
uv_os_gethostname(). Prior to this commit, this logic was
duplicated in several places across libuv and Node.js alone.
PR-URL: https://github.com/libuv/libuv/pull/2175
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
There was a formatting error that prevented the uv_get_free_memory
function from appearing on the page.
PR-URL: https://github.com/libuv/libuv/pull/2163
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
This reverts commit e94c184c7c.
Concerns were raised about the suitability of this policy and I, for
one, agree with them.
Fixes: https://github.com/libuv/libuv/issues/2098
PR-URL: https://github.com/libuv/libuv/pull/2122
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Right now, docs don't make it clear when exactly does it become okay to
free memory belonging to `uv_handle_t`. It's only stated that
`uv_close` must be called before freeing the memory, which is a source
of confusion for new users: they call `uv_close(handle, NULL)`, then
free the memory (see e.g. #2078, https://stackoverflow.com/q/25615340).
PR-URL: https://github.com/libuv/libuv/pull/2087
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Added UV_PROCESS_WINDOWS_HIDE_CONSOLE and
UV_PROCESS_WINDOWS_HIDE_GUI for specifying if console or GUI
subprocess windows are to be hidden.
Refs: https://github.com/nodejs/node/pull/24034
PR-URL: https://github.com/libuv/libuv/pull/2073
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
On Windows rename operation can fail randomly in presence of antivirus
or indexing software. Make `uv_fs_rename` retry up to four times with
250ms delay between attempts before giving up.
PR-URL: https://github.com/libuv/libuv/pull/1981
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Previously, we required the user to specify the expected read/write
flags for a pipe or tty. But we've already been asking the OS to tell us
what they actually are (fcntl F_GETFL), so we can hopefully just use
that information directly.
Fixes: https://github.com/libuv/libuv/issues/1936
PR-URL: https://github.com/libuv/libuv/pull/1964
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Change the position of UV_LS_LCHOWN, moving it to the end in order to go
around a bug due to it's initial position.
The original position of UV_LS_LCHOWN broke ABI compat, causing a binary
using UV_FS_REALPATH or UV_FS_COPYFILE to break, as the values point to
wrong function.
Refs: https://github.com/yarnpkg/yarn/issues/6043
Fixes: https://github.com/libuv/libuv/issues/1908
PR-URL: https://github.com/libuv/libuv/pull/1913
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This PR creates two new externally-facing APIs, uv_err_name_r() and
uv_strerror_r().
In keeping with the precedent set by POSIX, the *_r() suffix of these
two new methods indicate that the caller does the memory management and
passes in the memory that the output will be stored in, which provides
an alternative for the two existent methods (uv_err_name() and
uv_strerror()), which, when called with an unknown error code, leak a
few bytes of memory.
PR-URL: https://github.com/libuv/libuv/pull/1898
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno santiago.gimeno@gmail.com
