diff options
author | Yann Ylavic <ylavic@apache.org> | 2016-03-05 01:40:58 +0000 |
---|---|---|
committer | Yann Ylavic <ylavic@apache.org> | 2016-03-05 01:40:58 +0000 |
commit | e547c8577920802132994329ca50a554571fd308 (patch) | |
tree | 893502b6a98b9a3eb26821534f45db589cf0c67e /locks/beos/thread_cond.c | |
parent | 878278c3c98ab6c43ed645fef25d116dde16f22c (diff) | |
download | apr-e547c8577920802132994329ca50a554571fd308.tar.gz |
Merge r930508, r1667900, r1667901, r1667903, r1667962, r1669077, r1671292, r1732582 from trunk:
OS/2: Add an implementation of condition variables, derived from the Win32
implementation.
locks: introduce apr_{thread,proc,global}_mutex_timedlock().
For proc mutexes, the new mechanism APR_LOCK_DEFAULT_TIMED usable at creation time
allows for the best mechanism to be elected (unixes: 1 to 3, or specific: 4 to 7):
1. PROC_PTHREAD if pthread_mutex_timedlock() and pthread_mutex_set_robust_np()
are both available,
2. SYSV if semtimedop() is availale,
3. POSIXSEM if sem_timedwait() is available,
4. BeOS' acquire_sem_etc() if available,
5. NetWare falls back to apr_thread_mutex_timedlock() as for others functions,
6. OS2's DosRequestMutexSem(),
7. Windows' WaitForSingleObject().
Otherwise (like when fcntl and flock only are availble, if that's ever possible),
APR_ENOTIMPL is returned.
For thread mutexes, the new flag APR_THREAD_MUTEX_TIMED, usable at create()
time still, allows to switch to an implementation using a condition variable
and apr_thread_cond_timedwait() when if no native mechanism is available (eg.
NetWare, pthreads but without pthread_mutex_timedlock() available).
On windows, this initializes a WaitForSingleObject()able handle (Mutex) instead
of the fastest (but not timeout-able) CRITICAL_SECTION used by default.
All apr_{thread,proc,global}_mutex_timedlock() functions can take a relative or
absolute time, thanks to the last (boolean) argument.
Test suite updated accordingly.
Follow up to r1667900: revert spurious change on test/abts_tests.h.
Follow up to r1667900: fix comments.
Follow up to r1667900: handle negative (infinite) timeout in mutex/cond timedlock/timedwait.
locks: follow up to r1667900.
In apr_global_mutex_timedlock(), we can avoid converting from relative to
absolute time if thread locking is not needed.
make internal function static to avoid a warning
Follow up to r1667900: Avoid a circular reference (PR 59068).
Submitted by: bjh, ylavic, ylavic, ylavic, ylavic, ylavic, trawick, ylavic
Reviewed/backported by: ylavic
git-svn-id: https://svn.apache.org/repos/asf/apr/apr/branches/1.6.x@1733684 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'locks/beos/thread_cond.c')
-rw-r--r-- | locks/beos/thread_cond.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/locks/beos/thread_cond.c b/locks/beos/thread_cond.c index 44189d908..a0978c008 100644 --- a/locks/beos/thread_cond.c +++ b/locks/beos/thread_cond.c @@ -81,7 +81,7 @@ APR_DECLARE(apr_status_t) apr_thread_cond_create(apr_thread_cond_t **cond, static apr_status_t do_wait(apr_thread_cond_t *cond, apr_thread_mutex_t *mutex, - int timeout) + apr_interval_time_t timeout) { struct waiter_t *wait; thread_id cth = find_thread(NULL); |