Revert 1790490 (r1790488 from trunk), was;

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/branches/1.6.x@1795940 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 11 insertions, 1 deletions

diff --git a/locks/win32/thread_mutex.c b/locks/win32/thread_mutex.c
index 05dc3d5fb..cd0ccf5ba 100644
--- a/locks/win32/thread_mutex.c
+++ b/locks/win32/thread_mutex.c
@@ -115,7 +115,8 @@ APR_DECLARE(apr_status_t) apr_thread_mutex_trylock(apr_thread_mutex_t *mutex)
 }
 
 APR_DECLARE(apr_status_t) apr_thread_mutex_timedlock(apr_thread_mutex_t *mutex,
-                                                     apr_time_t timeout)
+                                                     apr_time_t timeout,
+                                                     int absolute)
 {
     if (mutex->type != thread_mutex_critical_section) {
         DWORD rv, timeout_ms;
@@ -123,6 +124,15 @@ APR_DECLARE(apr_status_t) apr_thread_mutex_timedlock(apr_thread_mutex_t *mutex,
             timeout_ms = INFINITE;
         }
         else {
+            if (absolute) {
+                apr_time_t now = apr_time_now();
+                if (timeout > now) {
+                    timeout -= now;
+                }
+                else {
+                    timeout = 0;
+                }
+            }
             timeout_ms = apr_time_as_msec(timeout);
         }
         rv = WaitForSingleObject(mutex->handle, timeout_ms);