summaryrefslogtreecommitdiff
path: root/test/testlock.c
diff options
context:
space:
mode:
authorYann Ylavic <ylavic@apache.org>2017-04-07 00:01:16 +0000
committerYann Ylavic <ylavic@apache.org>2017-04-07 00:01:16 +0000
commitf7b5a5f20e3edfb8ef2f4077147acb0bf17b3fab (patch)
tree5c5c8a818d677acc7cf00a9b3cd5bfbf9a669977 /test/testlock.c
parent0ea4c151aa5f650867a0afa3e92f90fc1bdbf114 (diff)
downloadapr-f7b5a5f20e3edfb8ef2f4077147acb0bf17b3fab.tar.gz
locks: follow up to r1667900.
Axe the 'absolute' argument of apr_{thread,proc,global}_mutex_timedlock() which was confusing, hence 'timeout' is always relative now. It still makes sense (to me) to handle a negative timeout as INFINITE, a nul one as IMMEDIATE, and a positive one as an upper bound timeout (like most if not all of the underlying system calls...). git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1790488 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'test/testlock.c')
-rw-r--r--test/testlock.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/test/testlock.c b/test/testlock.c
index 45eddb02e..095134e05 100644
--- a/test/testlock.c
+++ b/test/testlock.c
@@ -91,7 +91,7 @@ static void *APR_THREAD_FUNC thread_mutex_function(apr_thread_t *thd, void *data
while (1)
{
if (data) {
- apr_thread_mutex_timedlock(thread_mutex, *(apr_time_t *)data, 0);
+ apr_thread_mutex_timedlock(thread_mutex, *(apr_time_t *)data);
}
else {
apr_thread_mutex_lock(thread_mutex);
@@ -358,7 +358,7 @@ static void test_timeoutmutex(abts_case *tc, void *data)
ABTS_INT_EQUAL(tc, 0, apr_thread_mutex_lock(timeout_mutex));
for (i = 0; i < MAX_RETRY; i++) {
begin = apr_time_now();
- s = apr_thread_mutex_timedlock(timeout_mutex, timeout, 0);
+ s = apr_thread_mutex_timedlock(timeout_mutex, timeout);
end = apr_time_now();
if (s != APR_SUCCESS && !APR_STATUS_IS_TIMEUP(s)) {