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.
