We also tell the compiler it is not allowed to reorder the PAUSE
instruction relative to other instructions. It is a mostly theoretical
issue, but better safe than sorry.
PR-URL: https://github.com/libuv/libuv/pull/2590
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This is an attempt to fix some resource management issues on Windows.
Win32 sockets have an issue where it sends an RST packet if there is an
outstanding overlapped calls. We can avoid that by being certain to
explicitly cancel our read and write requests first.
This also removes some conditional cleanup code, since we might as well
clean it up eagerly (like unix). Otherwise, it looks to me like these
might cause the accept callbacks to be run after the endgame had freed
the memory for them.
The comment here seems mixed up between send and recv buffers. The
default behavior on calling `closesocket` is already to do a graceful
shutdown (see
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-closesocket
with default l_onoff=zero) if it is the last open handle. The expected
behavior if there are pending reads in flight is to send an RST packet,
notifying the client that the server connection was destroyed before
acknowledging the EOF.
Additionally, we need to cancel writes explicitly: we need to notify
Win32 that it is okay to cancel these writes (so it doesn't also
generate an RST packet on the wire).
Refs: https://github.com/libuv/libuv/pull/3035
Refs: https://github.com/nodejs/node/pull/35946
Refs: https://github.com/nodejs/node/issues/35904
Fixes: https://github.com/libuv/libuv/issues/3034
PR-URL: https://github.com/libuv/libuv/pull/3036
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
These functions are declared with one set of conditionals in the
header, and defined with another set of conditionals in the c file.
This commit makes all decisions regarding `uv__{nonblock,cloexec}_ioctl`
depend on a boolean macro instead.
There's one function that expects `uv__nonblock_ioctl` to be defined,
so that bit of the function is also conditionally compiled.
PR-URL: https://github.com/libuv/libuv/pull/3163
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Still returns ENOSYS, until the send/recv functions are implemented.
PR-URL: https://github.com/libuv/libuv/pull/3040
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Just like the unix counterpart, uv_fs_read and uv_fs_write should throw
an EBADF instead of manually throwing an EPERM when the passed fd has
not been opened with the right access flags.
PR-URL: https://github.com/libuv/libuv/pull/3180
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
`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>
Windows API gethostname(buffer, size) return unicode string in char
array. It will cause garbled code if the host name contains non ascii
characters without cast into multi byte char.
This change keep the same encoding with the implementation on
Unix/macOS platform, which is utf-8.
Requires Windows 8 / Server 2012.
Fixes: https://github.com/libuv/libuv/issues/3148
PR-URL: https://github.com/libuv/libuv/pull/3149
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This is more clear about the intended semantics with multiple threads.
PR-URL: https://github.com/libuv/libuv/pull/3124
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
libuv is packaged for OmniOS, an illumos distribution (OpenSolaris fork), and on that platform `libdl.so` is just a legacy stub library that does not need to be linked. `dlopen()` and friends are present in libc.
Changing to using `AC_SEARCH_LIBS()` instead of `AC_CHECK_LIB()` stops the unnecessary linking of libdl.
PR-URL: https://github.com/libuv/libuv/pull/3113
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
When compiling the current code MSVC prints this warning:
warning C4090: '=': different 'const' qualifiers
This warning was introduced with dc6fdcd where the `(char*)` cast for
the call to `wcstombs` was removed.
Re-adding this cast to silence the warning.
PR-URL: https://github.com/libuv/libuv/pull/3146
Refs: https://github.com/libuv/libuv/pull/2938
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The TAP specification [1] explicitely states:
A harness must only read TAP output from standard output and
not from standard error.
[1] https://testanything.org/tap-specification.html
PR-URL: https://github.com/libuv/libuv/pull/3153
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
PR-URL: https://github.com/libuv/libuv/pull/3166
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
IBM i interface names are based off the associated line description.
Since line descriptions are objects, they have 10 character limit on
their names. However, since IBM i 7.2 interface names may be up to 16
characters long if the interface is for a a VLAN (eg. MYETHLINE1.4094).
To handle this, we must strip off a VLAN ID to get the actual line
description name, since that's what the QDCRLIND API wants. One issue
exists because line descriptions can contain periods and numbers; so
for interface names less than 10 characters long ETH2.4 could be a line
description name or it could be ETH2 with VLAN 4. We follow the
method that the XPF ioctls use: try the interface name directly first
and if an error occurs, try to strip off the VLAN ID.
https://www.ibm.com/docs/en/i/7.4?topic=ssw_ibm_i_74/apis/ioctl.htm#unotes
Fixes: https://github.com/libuv/libuv/issues/3062
PR-URL: https://github.com/libuv/libuv/pull/3144
Reviewed-By: Richard Lau <rlau@redhat.com>
The previous implementation using rcepool would return a value that is
slightly off from the true value of the system's total memory. So use
CVTRLSTG to get total memory instead, which is more accurate. For more
information on CVTRLSTG, see MVS Data Areas Volumes 1 and 3.
Co-authored-by: Gaby Baghdadi <49249542+gabylb@users.noreply.github.com>
PR-URL: https://github.com/libuv/libuv/pull/3141
Reviewed-By: Richard Lau <rlau@redhat.com>
The previous implementation of `uv_get_free_memory()` on z/OS return
incorrect values. This is because the rceafc field being dereferenced
for the memory values needs to be treated as unsigned int.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Co-authored-by: Alex Yung <alex.yung@ibm.com>
Co-authored-by: CW Cheung <ccw.280231@ca.ibm.com>
PR-URL: https://github.com/libuv/libuv/pull/3141
Reviewed-By: Richard Lau <rlau@redhat.com>
Implementation is based on RLIMIT_MEMLIMIT.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
PR-URL: https://github.com/libuv/libuv/pull/3133
Reviewed-By: Richard Lau <rlau@redhat.com>
Thread Sanitizer can't intercept syscall(SYS_close, fd) that's used
instead of close(fd); on Linux. That leads to false positives as Thread
Sanitizer thinks the descriptor is still being used by the thread.
clang defines pre- and post- syscall actions, so wrap the close
syscall() into the action macros. For gcc, use close() from glibc
instead of the syscall. This allows the thread sanitizer to intercept
closing of the file descriptor when libuv is compiled with Thread
Sanitizer.
PR-URL: https://github.com/libuv/libuv/pull/3112
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
`pthread_attr_init` is highly unlikely to fail on macOS. Removing the
fallback behavior here to be consistent with other parts of libuv (e.g.
`src/unix/thread.c`), which simply call `abort()`.
PR-URL: https://github.com/libuv/libuv/pull/3132
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This fixes `SIGBUS` crashes on macOS 10.15 due a new change in
`FSEvents.framework` that makes it allocate a large stack array for
event paths. (See the linked nodejs/node issue for details on the
`FSEvents.framework` memory requirements change itself.)
The existing size (`4 * PTHREAD_STACK_MIN` or 32KB) causes a stack
overflow when more than ~1000 events are received at once. Setting this
to `uv__thread_stack_size()` increases it to 8192KB (by default) on
64-bit machines. This value can be configured at runtime on macOS with
`ulimit -s <size-kb>`.
The 32KB limit was originally added to reduce virtual memory
fragmentation on 32-bit systems, which is not a concern on 64-bit
systems.
Fixes: nodejs/node#37697
Refs: joyent/libuv#964
PR-URL: https://github.com/libuv/libuv/pull/3132
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This function will be used by `uv__fsevents_loop_init` in a future
commit to determine the initial FSEvents pthread stack size.
PR-URL: https://github.com/libuv/libuv/pull/3132
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
In both `test-tcp-open` and `test-udp-open`.
PR-URL: https://github.com/libuv/libuv/pull/3137
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
There is no CMAKE_LINKER_FLAGS_DEBUG.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
PR-URL: https://github.com/libuv/libuv/pull/3137
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
In the codebase we have used empty for loop for infinite conditions, so
to bring consistency replaced other occurrences of while in the codebase
with for loop.
PR-URL: https://github.com/libuv/libuv/pull/3128
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
