MSYS2 + MinGW-w64 have good support for autoconf, that should be the
preferred way of building libuv under MinGW.
PR-URL: https://github.com/libuv/libuv/pull/1000
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Treat both the base being NULL or the length being 0 as ENOBUFS.
PR-URL: https://github.com/libuv/libuv/pull/997
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When Windows resumes after sleep GetQueuedCompletionStatus timeout is
not updated. This commit adds a method for signaling all loops to
wake up and update their timers.
Fixes: https://github.com/nodejs/node/issues/6763
PR-URL: https://github.com/libuv/libuv/pull/962
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This reverts commit 7892bd6f76.
The reasoning for the original patch was flawed. On x86 systems
_InterlockedOr intrinsic must be used. MinGW also exposes the problem,
so reverting this gets rid of a warning.
PR-URL: https://github.com/libuv/libuv/pull/990
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Do not compile 'tty_pty' test for android.
PR-URL: https://github.com/libuv/libuv/pull/975
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
After 4ed29c2498 got fixed, when a CRT fd
is handed off to a pipe handle using uv_pipe_open libuv will close it
properly, so it's an error to do so ourselves.
PR-URL: https://github.com/libuv/libuv/pull/992
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
- Use atomic ops both to set and reset async_sent flag
- Remove the MinGW atomic ops, since Windows intrinsics are supported
- Remone thread-unsafe checks from uv_async_send
According to MSDN there are no alignment requirements. We could use
InterlockedExchange8, but that's only available on Windows >= 8.
This change is intended to make uv_async_send more resilient. It has to
be thread-safe, and that means that the handle could just have been
closed when uv_async_send was called. This case was previously not
handles (there is an inherent race condition). The new model is inspired
by the one used on the Unix side, which uses a single fd (or overlapped
in this case) to wakeup the loop and then process all pending async
handles. This makes handling those edge cases a lot simpler: when the
handle is closed it's removed from the handle queue, and then it's not
processed at all.
As a result of this change, async benchmarks work on Windows where they
previously failed with assertions.
PR-URL: https://github.com/libuv/libuv/pull/980
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This code has been disabled since 2011, I guess we're ok without it.
PR-URL: https://github.com/libuv/libuv/pull/971
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On OS X, special files like /dev/null and /dev/tty don't work with
kqueue. Libuv falls back to select() in that case but the initial
probe didn't handle EINTR.
Introduced in August 2012 in commit 731adaca ("unix: use select()
for specific fds on OS X"), this bug was only ten days away from
celebrating its fourth birthday.
PR-URL: https://github.com/libuv/libuv/pull/979
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
MinGW (from mingw.org) is really old, so stop pretending we support it.
Just support MinGW-w64, which works also works with 32bit Windows,
despite it's misleading name.
PR-URL: https://github.com/libuv/libuv/pull/969
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
It's now present on all supported macOS and iOS versions.
PR-URL: https://github.com/libuv/libuv/pull/966
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Same as we do for uv_handle_t and uv_req_t, they may come useful if we
need to get creative to keep ABI compatibility.
PR-URL: https://github.com/libuv/libuv/pull/967
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Libuv leaves loop->data unchanged in uv_loop_init() and uv_loop_done()
on Windows but it clobbered it on UNIX platforms. This commit fixes
that inconsistency.
PR-URL: https://github.com/libuv/libuv/pull/951
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
We not only check the return value, but also check the errno != 0.
Because in rare cases connect() will return -1 but the errno
is 0 (for example, on Android 4.3, OnePlus phone A0001_12_150227)
and actually the tcp three-way handshake is completed.
PR-URL: https://github.com/libuv/libuv/pull/936
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Imran Iqbal <imran@imraniqbal.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This commit causes uv_get_process_title() to:
- return EINVAL if the buffer is null or size is 0
- return ENOBUFS if the title is too big for the buffer
- null terminate the buffer on success
Fixes: https://github.com/libuv/libuv/issues/315
PR-URL: https://github.com/libuv/libuv/pull/928
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It was pointed out[0] that libuv could effectively enter an infinite
loop (but not a busy loop) under certain conditions when polling for
events:
1. When the architecture is 32 bits, and
2. When timeout > 0, i.e., finite, and
3. When timeout > max_safe_timeout (~30 minutes), and
4. When epoll_wait(timeout) returns 0, then
5. timeout was not properly updated on the next call to epoll_wait().
Inspection of the code uncovered a secondary bug where under a similar
set of circumstances the timeout could drift when the epoll_wait()
system call returned late.
[0] https://github.com/libuv/libuv/pull/354#discussion_r67837112
PR-URL: https://github.com/libuv/libuv/pull/922
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
uv_write_t can be reused safely only after the callback passed to
uv_write is fired.
PR-URL: https://github.com/libuv/libuv/pull/927
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
