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: http://svn.apache.org/repos/asf/apr/apr/trunk@1790488 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 1 insertions, 11 deletions

diff --git a/locks/win32/proc_mutex.c b/locks/win32/proc_mutex.c
index b51f856c0..7c3df23dc 100644
--- a/locks/win32/proc_mutex.c
+++ b/locks/win32/proc_mutex.c
@@ -165,8 +165,7 @@ APR_DECLARE(apr_status_t) apr_proc_mutex_trylock(apr_proc_mutex_t *mutex)
 }
 
 APR_DECLARE(apr_status_t) apr_proc_mutex_timedlock(apr_proc_mutex_t *mutex,
-                                                   apr_time_t timeout,
-                                                   int absolute)
+                                                   apr_time_t timeout)
 {
     DWORD rv;
 
@@ -174,15 +173,6 @@ APR_DECLARE(apr_status_t) apr_proc_mutex_timedlock(apr_proc_mutex_t *mutex,
         rv = WaitForSingleObject(mutex->handle, INFINITE);
     }
     else {
-        if (absolute) {
-            apr_time_t now = apr_time_now();
-            if (timeout > now) {
-                timeout -= now;
-            }
-            else {
-                timeout = 0;
-            }
-        }
         rv = WaitForSingleObject(mutex->handle, apr_time_as_msec(timeout));
         if (rv == WAIT_TIMEOUT) {
             return APR_TIMEUP;