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. > 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. 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. For each of these, perhaps _WIN32 _BEOSSEM _NWMUTEX etc. would be more appropriate labels, because overloading those on top of _DEFAULT led to this design confusion. Consider that use of os_get[_ex] os_set[_ex] requires intimate knowledge of the apr implementation and underlying mutex mechanism by platform, so I don't see this as a major complication.
