default locking ordering

[Jim Jagielski <ji...@jaguNET.com>]

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.

Comments?

(Might be the same with shared memory ordering as
well... I haven't looked).

Re: default locking ordering

[Jim Jagielski <ji...@jaguNET.com>]

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.

Re: default locking ordering

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

Bill

Re: default locking ordering

[Jim Jagielski <ji...@jaguNET.com>]

On Oct 12, 2005, at 3:44 PM, Jeff Trawick wrote:

> On 10/12/05, Jim Jagielski <ji...@jagunet.com> 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.
>>
>> Comments?
>>
>
> don't forget that hints are set for some platforms to override the
> selection algorithm; such hints are available to configure logic but
> not to proc_mutex.c unless some extra work is performed to convert
> hints into preprocessor symbols
>

Yeah, that's the tricky part... I'll see if anything I come
up with is cleaner that what we have. Just having those doubled
up APR_IFALLYES lines slap my sensitivities :)

Re: default locking ordering

[Jeff Trawick <tr...@gmail.com>]

On 10/12/05, Jim Jagielski <ji...@jagunet.com> 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.
>
> Comments?

don't forget that hints are set for some platforms to override the
selection algorithm; such hints are available to configure logic but
not to proc_mutex.c unless some extra work is performed to convert
hints into preprocessor symbols