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 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>
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>
The code made an implicit assumption that the 'len` variable passed
to the sendfile(2) syscall is not modified by the operating system
in case of an error other than EAGAIN or EINTR.
The man page leaves this unspecified on FreeBSD, DragonFly and
Darwin, so better check the error code which returns a valid
value in `len` explicitly (only EAGAIN and EINTR).
This fixes the test case for sendfile on DragonFly.
PR-URL: https://github.com/libuv/libuv/pull/466
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
\r is a single carriage return without line feed on all platforms,
including Windows.
PR-URL: https://github.com/libuv/libuv/pull/472
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Commit 0f1bdb6 ("threadpool: send signal only when queue is empty")
introduces a regression where work is not evenly distributed across
the thread pool because the work queue's condition variable is only
signalled when the queue is empty, even when there are waiting workers.
It doesn't turn into outright deadlock because there is always
at least one thread making forward progress but it does degrade
throughput, sometimes massively so.
Signalling whenever there are waiting workers fixes the throughput
issue while still keeping the number of uv_cond_signal() calls low,
which was the motivation for commit 0f1bdb6.
Fixes: https://github.com/libuv/libuv/pull/490
Fixes: https://github.com/libuv/libuv/issues/492
PR-URL: https://github.com/libuv/libuv/pull/493
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It's an error to do so, so just ignore it. The test would cause an
invalid memory access if the fix is undone.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On Windows we create multiple pipe handles (system handles) which are
attached to pending accept requests. Each of these will take turns in
replacing the reference in handle->handle, so make sure we allow for
that **only** for pipe servers.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On pipe servers handle->handle takes turns between the different server
handles, so after closing all of them just reset the dandling reference.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Makes uv_loop_init return an error code instead of aborting.
Currently uv_loop_init aborts if there are insufficient resources
available. As a user I want to be able to check the return code from
uv_loop_init and decide how I respond rather than having my process die.
PR-URL: https://github.com/libuv/libuv/pull/405
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
At least on OS X 10.10 "Yosemite", an EPROTOTYPE can occur
when trying to write to a socket that is shutting down.
By retrying the write after EPROTOTYPE, we correctly get EPIPE.
PR-URL: https://github.com/libuv/libuv/pull/482
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Make uv_err_name() and uv_strerror() return a dynamically allocated
string when the error code is not recognized.
It leaks a few bytes of memory but that can't be helped. Asserting
and aborting is, in my opinion, much less helpful.
Fixes: https://github.com/nodejs/node/issues/63
PR-URL: https://github.com/libuv/libuv/pull/467
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
For synchronous file operation requests (ones without a callback), there
is no need to make a copy of the arguments because they don't outlive
the scope of the function call.
PR-URL: https://github.com/libuv/libuv/pull/479
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The parentheses are unnecessary because what they wrap are not macro
arguments but function arguments that aren't evaluated by the macro.
PR-URL: https://github.com/libuv/libuv/pull/479
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This allows writing and reading any amount of buffers,
regardless of what IOV_MAX may be defined as.
It also moves the IOV_MAX test from stream to core.
This is based on the excellent work of @bwijen in #269.
Refs: https://github.com/libuv/libuv/pull/269
PR-URL: https://github.com/libuv/libuv/pull/448
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_exepath() was not behaving correctly on AIX when the process was
invoked with a relative path.
The logic has been reworked to:
1) Use getargs() to retrieve the process arguments
2) Use realpath() to handle absolute and relative paths and
symbolic links
3) Check that a match when searching the PATH is executable (if
not search will continue)
PR-URL: https://github.com/libuv/libuv/pull/464
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add new UV__POLLRDHUP event to be emitted when EPOLLRDHUP(in Linux) or
EV_EOF(in BSD / OSX) is detected and only if UV_READABLE is set.
When a read returns ECONNRESET after a UV__POLLRDHUP event, emit EOF instead
of the error.
Add tcp-squelch-connreset test. Not to be run on Windows as it returns
ECONNRESET error.
Fixes in test-poll and test-tcp-open so they pass after these changes.
PR-URL: https://github.com/libuv/libuv/pull/403
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the console text color set by the user rather than assuming the
Windows default (white foreground on black background).
PR-URL: https://github.com/libuv/libuv/pull/431
Reviewed-By: Bert Belder <bertbelder@gmail.com>
UV_HANDLE_CONNECTED was defined, but never used anywhere - outside this if
condition inside uv__stdio_create. So this test can't be true.
UV_HANDLE_CONNECTION was meant.
A test was also added verifying the behaviour.
PR-URL: https://github.com/libuv/libuv/pull/404
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Silences the following runtime errors when compiling UBSan:
../src/unix/linux-core.c:181:9: runtime error: member access within null
pointer of type 'uv__io_t' (aka 'struct uv__io_s')
../src/unix/process.c:67:15: runtime error: member access within null
pointer of type 'uv_process_t' (aka 'struct uv_process_s')
../src/unix/process.c:91:15: runtime error: member access within null
pointer of type 'uv_process_t' (aka 'struct uv_process_s')
...
PR-URL: https://github.com/libuv/libuv/pull/422
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Once we are past uv__stream_init, the handle has been added to
loop->handle_queue, it needs to be undone in case of failure.
PR-URL: https://github.com/libuv/libuv/pull/414
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
OSX, other BSDs and SunoS fail with EAFNOSUPPORT when binding a socket created
with AF_INET to an AF_INET6 address or vice versa.
PR-URL: https://github.com/libuv/libuv/pull/407
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Introduce two new APIs:
int uv_tcp_init_ex(uv_loop_t*, uv_tcp_t* handle, int flags)
int uv_udp_init_ex(uv_loop_t*, uv_udp_t* handle, int flags)
The lower 8 bits of the flags field are used for the socket domain.
AF_INET, AF_INET6 and AF_UNSPEC are supported. If AF_UNSPEC is specified
the socket is created lazily, just like uv_{tcp,udp}_init.
Some Windows notes:
getsockname fails with WSAEINVAL if the socket is not bound. This could
potentially be improved by detecting the socket family and filling
the sockaddr_in/6 struct manually.
bind returns WSAEFAULT if we try to bind a socket to the wrong family.
Unix returns EINVAL.
PR-URL: https://github.com/libuv/libuv/pull/400
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This fixes a bug I have noticed with nodejs:
> cat test.js
console.log(process.execPath);
> node test.js (on DragonFly)
node test.js
> node test.js (on Linux)
node
PR-URL: https://github.com/libuv/libuv/pull/399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the same code path as FreeBSD does.
PR-URL: https://github.com/libuv/libuv/pull/399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
