On Sat, Jun 3, 2017 at 2:20 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Fri, Jun 2, 2017 at 6:02 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 8:37 PM, <wr...@apache.org> wrote:
>>> Author: wrowe
>>> Date: Fri Jun 2 18:37:33 2017
>>> New Revision: 1797416
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1797416&view=rev
>>> Log:
>>> On Windows, OS2 and BEOS, the singluar lock mechanisms were already
>>> compatible
>>> with timed locks, so there is no delta between DEFAULT and DEFAULT_TIMED.
>>>
>>> Avoid prohibited API changes to typical OS lock information.
>>
>> But these locks are also DEFAULT_TIMED, so a portable code (runnable
>> on these or Unixes) which like to check DEFAULT_TIMED to know whether
>> _timedlock() is available can't.
>
> You were changing the API behavior between 1.5.x and 1.7.x branches,
> and that's never permissible, so the code on 1.7.x was incorrect. It would
> also be awfully bad form in 2.0 to suddenly return a "different"ly identical
> mutex with a different lockmech value.
Agreed.
>
>> How about DEFAULT_TIMED = DEFAULT as we discussed already?
>
> That's a possibility, but not necessary. On the downside, that would be
> a compile time value. On unix, you may have compiled where there is
> _DEFAULT_TIMED of _SYSVSEM, but at runtime apr had been
> recompiled to use _POSIX. Worse yet, you would now force _DEFAULT
> to remain sysv if that was it's runtime identity, the entire choose-best
> logic would be bypassed if the _DEFAULT[_TIMED] enums were no
> longer constant.
I don't get it.
typedef enum {
APR_LOCK_FCNTL, /**< fcntl() */
APR_LOCK_FLOCK, /**< flock() */
APR_LOCK_SYSVSEM, /**< System V Semaphores */
APR_LOCK_PROC_PTHREAD, /**< POSIX pthread process-based locking */
APR_LOCK_POSIXSEM, /**< POSIX semaphore process-based locking */
APR_LOCK_DEFAULT, /**< Use the default process lock */
#ifdef _UNIX_LIKE_
APR_LOCK_DEFAULT_TIMED /**< Use the default process timed lock */
#else
APR_LOCK_DEFAULT_TIMED = APR_LOCK_DEFAULT
#endif
} apr_lockmech_e;
is a constant thing no?
>
> You identified it yourself, the _DEFAULT is a request for the appropriate
> mutex type, on unix, _DEFAULT is not returned for the lockmech, but the
> actual _SYSVSEM, or _POSIX, or _FILE or whatever was used.
>
> Likewise _DEFAULT_TIMED means nothing on read, only on set, as
> it is a request for a class of lockmech that is most appropriate *and*
> is capable of _TIMED ops.
Right, but why apr_os_mutex_set[_ex](DEFAULT_TIMED) should fail on
Windows, OS2 and BEOS?
APR_LOCK_DEFAULT_TIMED = APR_LOCK_DEFAULT allows this, and does not
break with _get[_ex]() either I think.
