Since API level 21 (Android 5.0) the non-standard pthread function
pthread_cond_timedwait_monotonic_np has been removed in favour of
the standard pthread_cond_timedwait which libuv normally uses on
Linux.
This commit changes the detection of the Android OS to account for
the removal of the function via the #define
HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC which is only present in older
API levels.
Fixes: https://github.com/libuv/libuv/issues/172
PR-URL: https://github.com/libuv/libuv/pull/176
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
59658a8de7 changed uv_thread_self()
to return uv_thread_t, but uv_thread_t is a thread's HANDLE while
uv_thread_self() returns the current thread's id.
This means that uv_thread_equal() is also broken, as we are
potentially comparing HANDLES to ids.
Changed uv_thread_self() to return the current thread's creation handle.
Fixed small doc issue.
Make uv_barrier_wait() return a boolean value indicating whether this
thread was the "serializer".
From `man pthread_barrier_wait`:
Upon successful completion, the pthread_barrier_wait() function
shall return PTHREAD_BARRIER_SERIAL_THREAD for a single (arbitrary)
thread synchronized at the barrier and zero for each of the other
threads.
Exposing that information from libuv is useful because it can make
cleanup significantly easier:
if (uv_barrier_wait(&barrier) > 0)
uv_barrier_destroy(&barrier);
Signed-off-by: Fedor Indutny <fedor@indutny.com>
On some systems, clock_gettime(CLOCK_MONOTONIC) is only serviced from
the vDSO when the __vdso_clock_gettime() wrapper is confident enough
that the vDSO timestamp is highly accurate. When in doubt, it falls
back to making a traditional SYS_clock_gettime system call with all
the overhead that entails.
While a commendable approach, it's overkill for our purposes because we
don't usually need high precision time. That's why this commit switches
to CLOCK_MONOTONIC_COARSE for low-precision timekeeping, provided said
clock has at least a one millisecond resolution.
This change should eliminate the system call on almost all systems,
including virtualized ones, provided the kernel is >= 2.6.32 and glibc
is new enough to find and parse the vDSO.
Uses the pthread_key_{create,delete} and pthread_{get,set}specific
functions on UNIX platforms, Tls{Alloc,Free} and Tls{Get,Set}Value
on Windows.
Fixes#904.
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.
Tested most of my compilation in the previous patch on NodeJS
and extracted the patches from there. This patch ensures libuv
will be capable of building standalone as well, both with gyp
and Makefiles.
Build documentation was added to the README.md file.
Some tests are failing, and I have not heavily investigated
the reasons. The failures are generally on errors, and are
likely related to differences between fully POSIX-compatible
systems and android.
Merge the OS X specific implementation of uv_cond_timedwait() with the
generic one. The only difference is that it now uses mach_absolute_time
instead of gettimeofday.
This commit renames the various uv_hrtime() implementations to uv__hrtime().
Libuv uses the high-res timer internally in performance-critical code paths.
Calling the non-public version avoids going through the PLT when libuv is
compiled as a shared object.
The exported uv_hrtime() now has a single definition in src/unix/core.c that
calls uv__hrtime().
A future optimization is to lift the uv__hrtime() declarations into header
files so they can be inlined at the call sites. Then again, linking with -flto
should accomplish the same thing.
Read/write locks are emulated with critical sections on Windows XP and Vista
because those platforms don't have a (complete) native read/write lock API.
