Retrying seems like a bad idea in a multi-threaded program because the
man page leaves it unspecified whether the file descriptor is closed
after EINTR.
It's probably an academic issue because as far as I have been able to
establish by checking the kernel sources, dup2 and dup3 never actually
return EINTR. For dup3, this appears to have been the case since its
introduction in v2.6.27; for dup2, it goes back to at least v2.6.18.
Fixes: https://github.com/libuv/libuv/issues/462
PR-URL: https://github.com/libuv/libuv/pull/608
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
By default, FreeBSD has net.inet6.ip6.v6only set to 1 (i.e., no dual stack
support). A new function can_ipv6_ipv4_dual is added to check its value and
decide whether `udp_dual_stack` test must be skipped or not.
PR-URL: https://github.com/libuv/libuv/pull/614
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Fixes a compilation problem in some platforms (notably OSX) after
6490c50.
PR-URL: https://github.com/libuv/libuv/pull/618
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
uv_(get|set)_process_title is not implemented for AIX. See unix/aix.c
PR-URL: https://github.com/libuv/libuv/pull/616
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Previously, libuv didn't return the correct error code when attempting
to close an invalid file descriptor with `uv_fs_close()`.
PR-URL: https://github.com/libuv/libuv/pull/613
Reviewed-by: Bert Belder <bertbelder@gmail.com>
When duplicating the socket handle being sent the target process
id is defaulted to the current process id. This enables uv_write2
to be used for thread-clustering in addition to process-clustering on
multi-threaded programming languages.
The ipc tests are updated to run in two modes. In the _inproc mode
the echo work is done on a second thread instead of in a second
process.
An internal function int uv_current_pid() is added to the windows
specific code which caches the value of GetCurrentProcessId(). This
means uv_write2 does not call GetCurrentProcessId() every inprocess
send.
Refs: https://github.com/joyent/libuv/issues/926
PR-URL: https://github.com/libuv/libuv/pull/540
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The pthread_mutex_lock() and pthread_mutex_unlock() calls logically
cannot fail in uv__fs_write() but let's check the return value anyway:
cosmic rays and memory corruption do happen.
PR-URL: https://github.com/libuv/libuv/pull/603
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
I think this makes it clear that the flags can't contain any other
information.
PR-URL: https://github.com/libuv/libuv/pull/592
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
fork and the exec functions are marked prohibited on tvOS and watchOS,
so referencing them causes compile errors.
This adds preprocessor conditionals to avoid calling them for those
targets.
PR-URL: https://github.com/libuv/libuv/pull/580
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
In FreeBSD 10.2 the test sometimes times out because the "touch file"
timer fires before the "watch file" event has been registered in the
kqueue. Increasing the timeout value seems to fix the issue.
PR-URL: https://github.com/libuv/libuv/pull/581
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The atomics that are in place of a lack of x86 cmpxchg are a GCC
specific intrinsic. When compiling for Solaris on a SPARC platform
with a non-gcc compiler, this prevents a successful build. This commit
will rely on a Solaris Studio specific preprocessor macro to redefine
the GCC intrinsic name to be the Solaris Studio one instead.
PR-URL: https://github.com/libuv/libuv/pull/569
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On some embedded devices (arm-linux-uclibc based ip camera),
sysconf(_SC_IOV_MAX) can not get the correct value. The return
value is -1 and the errno is EINPROGRESS. Degrade the value to 1.
PR-URL: https://github.com/libuv/libuv/pull/573
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Commit 0199955 ("fs: undo uv__req_init when uv__malloc failed")
mistakingly unregisters the requests unconditionally in a few places,
resulting in memory corruption when it hasn't been registered first.
Fixes: https://github.com/libuv/libuv/pull/543
PR-URL: https://github.com/libuv/libuv/pull/567
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Valgrind blocks the setrlimit() system call. Print a warning and skip
the test, don't consider it a fatal error.
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Valgrind complains that the msg_control pointer points to uninitialized
memory. While the memory is only used for writing data to, not for
reading data from, and the warning is therefore bogus, it's still
annoying enough that I decided to squelch it by zeroing the memory.
The performance implications should be minimal because this code path
is only used when sending over a handle to another process.
The warning:
==14859== Syscall param sendmsg(msg.msg_control) points to
uninitialised byte(s)
==14859== at 0x5AF1A80: __sendmsg_nocancel (in
/usr/lib64/libpthread-2.21.so)
==14859== by 0x46350E: uv__write (stream.c:810)
==14859== by 0x464B24: uv_write2 (stream.c:1398)
==14859== by 0x421ACE: run_test (test-ipc-send-recv.c:104)
==14859== by 0x421DD1: run_test_ipc_send_recv_tcp
(test-ipc-send-recv.c:156)
==14859== by 0x406D2F: run_test_part (runner.c:404)
==14859== by 0x4058CD: main (run-tests.c:58)
==14859== Address 0xffefff934 is on thread 1's stack
==14859== in frame #1, created by uv__write (stream.c:742)
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Replace uses of QUEUE_FOREACH when the list can get modified while
iterating over it, in particular when a callback is made into the
user's code. This should fix a number of spurious failures that
people have been reporting.
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
All uses of QUEUE_SPLIT in libuv split the list at the head so introduce
a QUEUE_MOVE macro that automates that.
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_os_fd_t is HANDLE on Windows, but closesocket needs a SOCKET.
PR-URL: https://github.com/libuv/libuv/pull/534
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On AIX, the getsockname API does not operate on the UNIX domain sockets
Please see: https://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/
com.ibm.aix.commtrf2/getsockname.htm
This means that the internal helper routine uv_guess_handle in tty.c
fails in AIX, for common use cases.
There is no direct API support which helps identifying a UNIX domain
socket in AIX. getpeername() retrieves the information pertinent to
connected UNIX domain socket pairs, and using getpeername where
getsockname fails was a good workaround. However, there are edge cases
where one end of a socketpair comes for introspection while the other
end has been closed, which causes getpeername to fail.
A better solution is derived based on these facts:
1.getsockname() on a broken / un-broken socketpair does not actually
fail with -1, instead it returns 0. However, the API does not modify
the socketaddr structure passed to it, with the socket information.
2.This behavior of getsockname is observed only for UNIX domain socket,
among all possible types of sockets which I tested - ~30 of them.
So a practical and stable workaround for AIX is to return
UV_UNKNOWN_HANDLE if getsockname fails. If it passes and the length
of the structure returned is 0 then we know that the type is AF_UNIX
and return UV_NAMED_PIPE , otherwise we inspect in the same way as for
other platforms to derive the type.
PR-URL: https://github.com/libuv/libuv/pull/539
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
They're no longer needed, since the Windows-native SRWLock functions are
no longer used.
PR-URL: https://github.com/libuv/libuv/pull/525
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Previously, on Windows Vista and later, we'd use the Windows native
SRWLock APIs. However they turned out to be semantically incompatible
with pthread read-write locks and/or plain buggy. This patch makes sure
that the custom implementation that was previously only used on old
Windows versions is now used everywhere.
This patch fixes a number of issues with the old fallback
implementation. Specifically:
* The reader count would not be incremented when a thread successfully
acquired a read lock while another thread *also* held a read lock.
* `uv_rwlock_tryrdlock()` and `uv_rwlock_trywrlock()` now
consistently return UV_EBUSY when a lock couldn't be acquired.
* Any unexpected errors now cause libuv to abort, with the exception of
`uv_rwlock_init()`.
See also https://github.com/libuv/libuv/issues/515.
PR-URL: https://github.com/libuv/libuv/pull/525
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Fold EAGAIN into EBUSY, and make it the only acceptable error.
PR-URL: https://github.com/libuv/libuv/pull/535
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On AIX, it is correct to include AIX specific include files.
This is similar to all other platforms (ex. darwin, linux).
Signed-off-by: Neil Mushell <nmushell@bloomberg.net>
PR-URL: https://github.com/libuv/libuv/pull/521
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
On AIX with the native xlC compiler, the compiler supports sync
compare swap and compare in two flavors:
1 __compare_and_swap
2 __compare_and_swaplp
This differs from the gcc version of this function in name. The
second version of this function supports 8-byte boundary for
a doubleword. Therefore, the macro logic checks:
if (AIX OS AND using xlC compiler)
if (64bit)
__compare_and_swaplp /* 64 bit version */
else
__compare_and_swap
endif
endif
Signed-off-by: Neil Mushell <nmushell@bloomberg.net>
PR-URL: https://github.com/libuv/libuv/pull/521
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Before this patch an uv_mutex_t (backed by a critical section) could be
released by a tread different from the thread that acquired it, which is
not allowed. This is fixed by using a semaphore instead.
Note that the affected code paths were used on Windows XP and Windows
Server 2003 only.
Fixes: https://github.com/libuv/libuv/issues/515
PR-URL: https://github.com/libuv/libuv/pull/516
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
In FreeBSD if connect is called and the queue of pending connections(backlog)
is full, the call is automatically rejected with ECONNRESET. In the tests, 100
connections were tried and the backlog of both servers is 12, so the error.
To fix ipc_listen_before_write and ipc_listen_after_write, the backlog of the
server has been increased to 128.
PR-URL: https://github.com/libuv/libuv/pull/504
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv__close() does not set errno, it returns the error. It also never
returns EINTR, it always maps it to EINPROGRESS.
PR-URL: https://github.com/libuv/libuv/pull/512
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
