httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: APR locks
Date Fri, 01 Oct 1999 14:12:50 GMT

Pools are the primary customer of locks right now.  So they, at least,
should get what they need to "play nice".

> BTW,  ap_create_mutex(), et. al are #defined to (0) in apr_lib.h,  so
> apr_pools are not being serialized.

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.

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.

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.  But then it is always dangerous
to encourage such enthusiasms.

 - ben

Mime
View raw message