apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: default locking ordering
Date Wed, 12 Oct 2005 19:03:32 GMT

On Oct 12, 2005, at 2:45 PM, William A. Rowe, Jr. wrote:

> Jim Jagielski wrote:
>
>> It's looking like the logic in selecting the default lock
>> method is somewhat wonky... We recreate the order, kinda, in
>> 2 places (configure.in and proc_mutex.c), and have
>> a combo of APR_HAS and APR_USE taken from the old 1.3
>> logic.
>> I'd like to propose streamlining it, doing away with the
>> APR_USE stuff and having the default order specified
>> fully in proc_mutex.c.
>>
>
> APR_HAS_ means that you can directly request a specific kind of
> lock, which is useful.
>
> APR_USE_ really should result in only one value, which reflects
> the 'default choice' for that platform.
>
> It probably would have been clearer if we had
>
> #define APR_HAS_QUIRK_FOO
> #define APR_HAS_QUIRK_BAR
>
> #define APR_USE_QUIRK apr_quirk_bar
>
> but then again, that has it's own issues.
>
> In any can, APR_USE_QUIRK_XXX should only have occurred once, so
> there's no potential that in one code path, it evaluated _FOO first,
> and in another code path, it may evaluate _BAR first, causing major
> pain and commotion.
>

The rub, as I said, is that we place the order in configure.in
instead of in proc_mutex.c. Not only that, but we clean up
the doubling of the APR_HAS_ and APR_USE configure.in
segments... let em work up a patch to show what I mean.


Mime
View raw message