On Wed, Aug 29, 2001 at 11:28:04AM -0700, Ryan Bloom wrote:
> We should only keep both API's for the short term. Any API that we release
> in a beta we need to support forever, so I am VERY much against releasing
> a beta with the old locking API, because it is a very poor API.
I have fundamental
On Wednesday 29 August 2001 11:25, Justin Erenkrantz wrote:
> On Wed, Aug 29, 2001 at 10:50:12AM -0700, Ryan Bloom wrote:
> > My only other comment, is that while doing development, it would be
> > REALLY cool if we could have access to both API's, which should end up
> > pointing to the same imple
On Wed, Aug 29, 2001 at 10:50:12AM -0700, Ryan Bloom wrote:
> My only other comment, is that while doing development, it would be REALLY
> cool if we could have access to both API's, which should end up pointing to
> the same implementation.
+1 *if* we keep both APIs. Otherwise, +0 - I'm not aga
On Wednesday 29 August 2001 09:53, Aaron Bannert wrote:
++1. As I have said all along, the common function for all locks, was
a point of contention between Manoj and I. I won, but I was wrong. It's
time to fix that mistake.
> Here are a few questions I have:
>
> 1) Do we also need these? I rea
The following is a proposed API change to the apr_lock.h interface. It basicly
breaks out the lock types into the 4 main types, then adds condition variables.
I'd like to stimulate some discussion on this topic, and get some +1's to
proceed with the proposal (or parts of it at least):
- thread mut
