Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020610143610.00bd7578@pop3.rowe-clan.net>
Date: Mon, 10 Jun 2002 14:41:21 -0500
To: dev@apr.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PHP-DEV] Re: PHP profiling results under 2.0.37  Re:
  Performance of Apache 2.0 Filter
Cc: Andi Gutmans <andi@zend.com>, dev@httpd.apache.org
In-Reply-To: <5.1.0.14.2.20020608120717.03eae698@127.0.0.1>
References: <5.1.0.14.2.20020608103701.03d93ec0@127.0.0.1>
 <3D018433.5050600@cnet.com>
 <Pine.LNX.4.44.0206071625500.26484-100000@deepthought.cs.virginia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:08 AM 6/8/2002, Andi Gutmans wrote:

>I just checked and it seems like Apache APR memory pools use mutex locking.
>It'd be better to use functions like the Win32 ones which don't use mutex 
>locking (as we made sure that only one thread allocates from its pool). 
>This could be achieved by compiling apr_pools.c without APR_HAS_THREADS 
>but I bet the default Apache 2 build has this enabled.

It's still pretty much a non-issue.  Although we've discussed thread-specific
allocators [that don't lock for allocation at all] win32 uses 
CriticalSections by
default, which adds 10 cpu instructions or so to obtain an uncontested mutex.

This probably would hurt Unix, so you might be interested in apr_pools
discussion of the apr_allocator approaches.  All these low-level discussions
are on APR, so I'm directing this discussion to that platform.

Nice to see another library leaning on APR [or at least, the Zend deployment
for PHP/Apache :-]

Bill