Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <84C7BDB9-B85E-4230-8B22-780DBEA8621A@jaguNET.com>
References: <20170405162401.DBD523A06C9@svn01-us-west.apache.org>
 <BE43B989-6285-4477-9A74-800E5C9F26D9@jaguNET.com> <CAKQ1sVNkJNbp=b6ftVqjMRFdMsOitcJuF8e0-AWDATcz5ztz6w@mail.gmail.com>
 <84C7BDB9-B85E-4230-8B22-780DBEA8621A@jaguNET.com>
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Wed, 5 Apr 2017 19:25:02 +0200
Message-ID: <CAKQ1sVMzP5Af+jk21te79LCHUTqUC0r=KPa3d4MpU_s6zOYDKA@mail.gmail.com>
Subject: Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c
To: Jim Jagielski <jim@jagunet.com>
Cc: apr-dev <dev@apr.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Wed, 05 Apr 2017 17:25:07 -0000

On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski <jim@jagunet.com> wrote:
> Your log is:
>
>    Follow up to r1667900: semtimedop() should be passed a relative timeout rather
>    then absolute.
>
> which implies that this fix is to adjust the calling convention for
> semtimedop()... but your code refers to proc_mutex_sysv_tryacquire()...
>
> Hope that makes it clearer.

APR_DECLARE(apr_status_t) apr_proc_mutex_timedlock(apr_proc_mutex_t *mutex,
                                                   apr_time_t timeout,
                                                   int absolute);

So the API allows the caller to specify whether the passed in timeout
value is absolute or relative (to now).
So depending on the underlying/native timedlock function, we have to
switch from the one to the other before the syscall.

semtimedop() expects a relative timeout, so if the caller gives an
absolute one we make it relative (by substracting now), and if the
result is negative (i.e. the given absolute time is the the past), we
act return of a non-blocking trylock

Why isn't it correct, should we error out or block indefinitely?