httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: APR locks
Date Fri, 01 Oct 1999 14:44:58 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.

Easy enough to put it in.  :)

> 
> apr_lock.h belongs in apr_lib.h not apr_portable right?

It definately NEEDS to be in apr_portable, but it also needs to be in
apr_lib.  It's an oversight.  :)

> 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.

I agree.  I think if we are going to divide the locks in any way at all,
it needs to be on type oif lock not scope of lock.  A lock is a lock is a
lock, whether that lock is cross process or cross thread shouldn't matter,
it is doing the same thing.  Protecting a section of code.  To break the
locks based on what they are affecting doesn't make any sense to me.  It
make more sense to break them on how they are protecting it.  But, that is
a discussion for another day.  :)

Ryan


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message