Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: No timed lock on MacOS
To: dev@apr.apache.org
References: <1DDDDE68-F525-4B2B-96F3-108D70A4B322@apache.org>
 <DAF12FC9-3637-4B13-8D69-3B6FB04A5E32@jaguNET.com>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@apache.org>
Organization: The Apache Software Foundation
Message-ID: <2cf5102d-389a-9480-0cd2-c6487b2d9083@apache.org>
Date: Wed, 5 Apr 2017 16:25:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <DAF12FC9-3637-4B13-8D69-3B6FB04A5E32@jaguNET.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 05 Apr 2017 14:25:56 -0000

On 05.04.2017 14:16, Jim Jagielski wrote:
> Hmmm.... Looking over the timed stuff, it seems that semtimedop()
> is used incorrectly.
>
> For both pthread_mutex_timedlock() and sem_timedwait(), the
> timeout variable is the actual wallclock time that the wait
> expires (eg: now+5mins). But, from what I can read about semtimedop(), its
> timeout really is a timeout (5mins). But it seems that we use it
> as if it was wall-clock time, which is WAY wrong...
>
> Can someone check to see what exactly the timeout value is for
> semtimedop()? Is it a delta or a wall-clock?


My man page says:

    semtimedop() behaves identically to semop() except that in those
    cases where the calling thread would sleep, the duration of that
    sleep is limited by the amount of elapsed time specified by the
    timespec structure whose address is passed in the timeout argument.


Looks like delta to me.

-- Brane