apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject lockmech ambiguity (Was: Release _timedlock API in 1.6.x?)
Date Thu, 01 Jun 2017 16:32:43 GMT
On Mon, May 22, 2017 at 3:22 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> From an API perspective, the single timeout argument looks consensual.
> So there may still be some bug(s) somewhere, which we would fix as
> always, but it would unlikely break existing applications since it's
> new feature, hence my positive vote...

I'm quite confused in retrospect with the apr_lockmech_e logic
as it exists in the 'oddball' architectures and the enum values.

APR_LOCK_DEFAULT looks to be the correct answer on the
oddball architectures. When we do an apr_os_proc_mutex_get_ex
we want to know what sort of void* object was just returned to us.
So long as the underlying lock object type didn't change (which it
doesn't appear to do so on the single-mutex-style architectures),
the right answer seems to remain APR_LOCK_DEFAULT.

APR_LOCK_DEFAULT_TIMED seems to express the desire to
have a lock mech that can be timed. But the underlying system
object doesn't vary, right? So apr should still report that it is one
APR_LOCK_DEFAULT. This could have been broken down into
explicit WIN32, NETWARE, BEOSSEM types. That seems like
an apr 2.0 change if we want it to happen.

As a short-term hack on these architectures, defining the enum
value of APR_LOCK_DEFAULT_TIMED as identical to the
APR_LOCK_DEFAULT value, both IsKindOf tests and the OS
datatype handling would remain correct, right?

On Unix, the problem in 1.7.x is broader... since a number of the
lockmech can be timed locks (and a number cannot). Again,
having retrieved the apr_os_proc_mutex, we need to know which
API handles it, not whether it is APR_LOCK_DEFAULT[_TIMED].
We might -also- want to know whether it is the default, and
whether it supported timed attempts (but if you know the API,
you know if there are timeouts available.)

Seems we heavily overloaded the recent timedlock and lockmech
changes to try to accomplish multiple purposes which are at odds
with one another, and need to mop this up before we can declare
1.7.x baked.

> PS: really sorry for the delay and the lack of activity these days, I
> had so few spare times...

Understandable, please give this some consideration when you
have cycles!

Mime
View raw message