Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Content-Type: text/plain;
  charset="iso-8859-1"
From: Ryan Bloom <rbb@covalent.net>
Reply-To: rbb@covalent.net
Organization: Covalent Technologies
To: Aaron Bannert <aaron@clove.org>, dev@apr.apache.org
Subject: Re: [PATCH] new lock APIs, rwlocks, condition variables
Date: Tue, 4 Sep 2001 06:29:13 -0700
References: <20010903210824.C6340@clove.org>
 <20010904045327.5245E46993@koj.rkbloom.net> <20010903220650.E6340@clove.org>
In-Reply-To: <20010903220650.E6340@clove.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20010904132914.1D15746993@koj.rkbloom.net>

On Monday 03 September 2001 22:06, Aaron Bannert wrote:

> > Adding that API to the thread locks API that is already there is making
> > the code harder to read.  If you split it out, then you can re-post the
> > entire patch in two pieces.  One, the current API re-org, which can be
> > generated by just doing a CVS diff.  The other the condition variable
> > API, which can be done by just posting the files with the API to the
> > list.
>
> Are you proposing I do something like apr_cond.h and apr_rwlock.h, leaving
> apr_thread_mutex_t and apr_proc_mutex_t in apr_lock.h? That may make this
> whole process much easier to digest.

Yeah, that is a good idea too.  That header file has always been too hard to 
read as well.  We could just include both of them from apr_lock.h if we wanted.
Not saying we should initially, but it would be possible.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------