Because libuv truncates the result of every call to INT32_MAX, it needs
to internally limit operations to INT32_MAX to be safe to use libuv.
This isn't an API change, since these operations weren't guaranteed to
work, and in fact usually failed in bizare ways already. This is very
long in coming, since we've had a lot of compiler warnings about this
and several PRs to fix this open for a decade, but the main consumers
that usually fix things didn't care (nodejs is 32-bit and julia patched
this downstream more than a decade ago, though it did run into this
again recently by mistake with sendfile).
Replaces #1501Fixes#3360
Split this off from endgame, so that it can be handled separately and
earlier, rather than trying to detect inside endgame which case we are
in. There appear to be some race conditions on the `handle` field still
however, which this does not yet attempt to address.
`uv_try_write2(stream, bufs, nbufs, send_handle)` acts like
`uv_try_write()` and extended write function for sending handles over a
pipe like `uv_write2`. It always returns `UV_EAGAIN` instead of
`UV_ENOSYS` on Windows so we can easily write cross-platform code
without special treatment.
PR-URL: https://github.com/libuv/libuv/pull/3183
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The behavior of `uv_read_start()` when the handle is closing or already
busy reading wasn't consistent across platforms. Now it is.
Fixes: https://github.com/libuv/help/issues/137
PR-URL: https://github.com/libuv/libuv/pull/2795
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.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>
Some long overdue refactoring that unifies more of the UNIX and Windows
backends.
PR-URL: https://github.com/libuv/libuv/pull/1904
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
* Don't silently ignore ERROR_OPERATION_ABORTED.
Code to silently ignore this error was added in c42a4ca, under the
false premise that this error is somehow equivalent to EINTR on posix
platforms. This isn't true; ERROR_OPERATION_ABORTED doesn't happen
unless the application explicitly aborts an I/O operation.
Silently ignoring this error elsewhere could potentially hide bugs,
hence libuv shouldn't do it. Instead, explicitly deal with it where
it is expected.
* Don't mark aborted reads as successful.
The worker thread used to call ReadFile() on synchronous pipes would
incorrectly mark cancelled read requests as successful, leading to
issues later on.
* Rely on main thread to restart aborted reads.
After a blocking ReadFile() call was cancelled, the worker thread
would previously attempt to restart it immediately, making
synchronization logic needlessly complex. Instead, we simply cancel
the operation, and leave it to the main loop to restart it if so
desired.
Since we now realy on the main thread to restart interrupted
ReadFile() calls, we can now have a single function interrupts a
synchronous read until the event loop restarts it again.
* Clean up uv__pipe_read_stop().
A single function to interrupt blocking reads also allows us to
remove weird logic in uv__pipe_read_stop() that quickly pauses and
unpauses a read operation in the hope of cancelling it.
* Assume CancelIo() and CancelSynchronousIo() are always available.
Since libuv doesn't support windows XP and Server 2003 any more, we
can assume that these APIs are always available, and do away with
branching around them.
PR-URL: https://github.com/libuv/libuv/pull/1843
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Fixes a TODO in src/threadpool.c. Updates the Windows code to drop the
unused `loop` parameter in calls to uv_req_init().
PR-URL: https://github.com/libuv/libuv/pull/1091
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
All the public structs and unions in the private fields in uv-win.h have
been named and all code accessing them updated, to comply to the C89
spec (which were previously causing warnings with the -pedantic flag).
PR-URL: https://github.com/libuv/libuv/pull/239
Reviewed-By: Andrius Bentkus <andrius.bentkus@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
All windows console writes are synchronous anyway, so there's no reason
for uv_try_write() to do nothing.
PR: https://github.com/libuv/libuv/pull/127
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
This implements locking around the blocking call to ReadFile to get
around a Windows kernel bug where a blocking ReadFile operation on a
stream can deadlock the thread. This allows uv_read_stop to immediately
cancel a pending IO operation, and allows uv_pipe_getsockname to
"pause" any pending read (from libuv) while it retrieves the
sockname information.
If unsupported by the OS (pre-Vista), this reverts to the old
(e.g. deadlock-prone) behavior
Closes#1313
Introduce `int uv_pipe_pending_count(uv_pipe_t*)` and
`uv_handle_type uv_pipe_pending_type(uv_pipe_t*)`. They should be
used in IPC pipe's read cb to accept incoming handles:
int count = uv_pipe_pending_count(pipe);
int i;
for (i = 0; i < count; i++) {
uv_handle_type type = uv_pipe_pending_type(pipe);
/* ... */
uv_accept(...);
}
`uv_try_write(stream, buf, size)` acts like `uv_write()`,
but without queueing actual write until UV_POLLOUT (or IOCP completion).
This is useful for doing writes using on-stack `uv_write_t` requests.
fix#1025
This commit changes the libuv API to return error codes directly rather
than storing them in a loop-global field.
A code snippet like this one:
if (uv_foo(loop) < 0) {
uv_err_t err = uv_last_error(loop);
fprintf(stderr, "%s\n", uv_strerror(err));
}
Should be rewritten like this:
int err = uv_foo(loop);
if (err < 0)
fprintf(stderr, "%s\n", uv_strerror(err));
The rationale for this change is that it should make creating bindings
for other languages a lot easier: dealing with struct return values is
painful with most FFIs and often downright buggy.
This patch adds the `uv_stream_set_blocking` API which makes all
uv_write calls to that stream blocking. It currently only works for
pipes, on windows.
This commit changes how the event loop determines if it needs to stay alive.
Previously, an internal counter was increased whenever a handle got created
and decreased again when the handle was closed.
While conceptually simple, it turned out hard to work with: you often want
to keep the event loop alive only if the handle is actually doing something.
Stopped or inactive handles were a frequent source of hanging event loops.
That's why this commit changes the reference counting scheme to a model where
a handle only references the event loop when it's active. 'Active' means
different things for different handle types, e.g.:
* timers: ticking
* sockets: reading, writing or listening
* processes: always active (for now, subject to change)
* idle, check, prepare: only active when started
This commit also changes how the uv_ref() and uv_unref() functions work: they
now operate on the level of individual handles, not the whole event loop.
The Windows implementation was done by Bert Belder.
This patch changes how uv-win uses the UV_SHUTTING and UV_SHUT flags.
UV_SHUT is now only used for tcp handles to track whether shutdown() has
actually been called. UV_SHUTTING has the more generic meaning of
"no longer readable". It would be good to replace it by an actual
UV_READABLE flag in the future.
This makes the shutdown_close_tcp and shutdown_close_pipe tests pass on
windows.
