httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: APR locks
Date Fri, 01 Oct 1999 15:10:03 GMT

> Well that's not right!  It's a legacy of the Unix pools not needing
> any multiplexing.  So, the current APR lock API isn't clever enough -
> i.e. apr_lockscope_e is missing APR_LOCK_NONE.
Sounds like a good addition.

>
> apr_lock.h belongs in apr_lib.h not apr_portable right?
>
> Aside: the 1.3 window's pool mutex are unnecessarily expensive using
> inter-process locking, but given the pattern of usage that's probably
> isn't a big deal.
It isn't too hard to change the pool locks to CriticalSections(). I've done
it in fact and could tell little difference in performance. That could be
because of the usage pattern or because the performance difference is
insignificant compared to the other performance problems in the Win32 port
(stat(), open() and read() consume a monster portion of the CPU cycles on
Win32. BTW, the native Win32 calls are significantly faster. I expect Apache
2.0 for Windows to be at least 50% faster serving static files than V1.3.
More if I can get accept socket reuse working. But I digress...)
>
> The dispatch to flavor of lock can be engineered N ways:
>  a. PROPOSED?:  do it in source at callers.
>  b. AS in 1.3:  do it at compile time, in the headers.
>  c. APR design: do it at runtime.
>  d. The every popular: assorted section of the above.
>
> I like b more than a, because the current primary user is already
> coded to have treat the mutex as an abstraction.  I like c more
> that b, but only slightly because I have heroic fantasies of
> pools and i/o pipelines that work in all three ways: user-serialized,
> intra-process, inter-process.
Option b does not lend itself to using CriticalSections and mutexs on
Windows in the same executable using the APR APIs. We either need seperate
API or do it like it's being done in APR now (runtime selectable, which as I
get into it, seems okay).

I brought this up because of the importance of avoiding unnecessary
complexity.  To remain successful, open source projects must be vigilant to
keep the barriers to entry (by new contributors) as low as possible (hence
the use of a common toolset like autoconf style build environments, gcc,
cvs, etc.).  Hiding too many details, I think, is not always the best way to
achieve simplicity (at least to open source develoeprs who tend to want to
understand all those details and not be passive users :-)

Bill


Mime
View raw message