Instead of creating a new mmap, how about using the same one
and adding a reference count?
--Brian
Cliff Woolley wrote:
On Tue, 26 Jun 2001, Cliff Woolley wrote:
Your right, this can do that. However, we really can't keep that from
happening. In reality, the mmap_setaside function should just
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as a complement to the
current intraprocess locks in APR. There are some places, like
the pool memory allocator, where a spinlock
Justin Erenkrantz wrote:
On Tue, Jun 26, 2001 at 10:49:42AM -0700, Brian Pane wrote:
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as a complement to the
current intraprocess
Yes, there's definitely a race condition there. I noticed that
too, and I thought it was intentional (i.e., that the lack of a
lock was a conscious choice to avoid a performance penalty
for apps in which pools aren't shared across threads) and
harmless (because there aren't any pools in Apache
I wrote:
For now, I'll hack together a spin lock prototype to see if it yields any
measurable improvement in httpd speed.
This is now done, and the short answer is that using a custom
spin lock implementation in place of pthread mutexes in the
pool allocator code doesn't measurably improve the
David Reid wrote:
OK, well I'll try to add some stuff to this discussion...
Last night I tried to get sms looking and acting as pools Basically I added
some stuff and munged my tree so that when apr_pool calls were made they
were answered in sms code. This is configurable via an --enable-sms
Cliff Woolley wrote:
On Thu, 28 Jun 2001, Brian Pane wrote:
I like the concept of registering threads' interest in an sms. But how do
you handle the need for synchronization in a parent sms? E.g., if an app
creates an global sms and then two different threads create sms_block
instances
Sander Striker wrote:
[...]
The child thread is register in the parent thread. So, in the case of
the first created thread, a lock will be created. This does not happen
in the stub.
That eliminates the first race condition, but not the second.
Consider this
usage:
* There are two global SMSs,
Ian Holsman wrote:
On 05 Jul 2001 22:59:25 +0100, David Reid wrote:
OK, to comment on this prior to the patch being posted...
I have SMS running as pools and the implementation I have manages to run the
server at 80% of the speed of pools. This is with no changes to the httpd
code except using
dean gaudet wrote:
On Mon, 2 Jul 2001, Brian Pane wrote:
On Mon, 2 Jul 2001, Brian Pane wrote:
then it should be possible to eliminate a system call by not doing the
initial read before the select.
Here's a patch that disables the read before the select, but only for
the HTTP client socket.
hey
Justin Erenkrantz wrote:
Yeah, David had some local changes that he didn't commit that were in
his sms_pools_patch.
Since we weren't building, I just committed the relevant chunks into
APR. Try again. Works here without his patch. This may make his
posted patch go freaky. Oh, well.
I may try
I used gprof to do some performance profiling of an httpd built
using SMS-based pools.
Below is the list of the top 100 functions, ranked by CPU usage.
(The full output of gprof, showing what functions contribute the
most invocations of what other functions, is ~300KB, so I haven't
included it
I added some instrumentation to apr_sms_trivial_malloc
to study in more detail where its bottlenecks were.
As a result, I found a few interesting phenomena:
1. The good news is that allocations of small amounts
of memory are very efficient. They almost always
take the fastest path through the
Sander Striker wrote:
I'll think out loud now:
Me too :-)
The solution might be adding specific allocation functions for SMS
implementations. These functions could look something like this:
APR_DECLARE(void *) apr_sms_child_malloc(apr_sms_t *sms,
apr_sms_t
Sander Striker wrote:
To be honest changing sms_trivial to use malloc instead of
apr_sms_malloc is
an easy move (just a few lines to change) so it's probably worth
trying and then seeing what we get...
Massive leakage :)
Remember how the apr_sms_reset code works; it does not have to
traverse
Jon Travis wrote:
[...]
Tables should definitely be moved to APR-util if they are to remain. As
for Apache, there are better structures that dictate general order than
the table. IMNSHO, the only reason tables are still in Apache is inertia.
Nobody wants to go through and change everything to a
Justin Erenkrantz wrote:
On Mon, Jul 09, 2001 at 08:14:26PM -0700, Jon Travis wrote:
Tables should definitely be moved to APR-util if they are to remain. As
for Apache, there are better structures that dictate general order than
the table. IMNSHO, the only reason tables are still in Apache is
Sander Striker wrote:
Cliff pointed out to me that using my homedir for this stuff might be
a better idea (instead of people pounding my ADSL).
I saw some hits on my box and think that people were scared away by
the size of the archive (~10MB). Sorry about that. In combination with
the speed of my
Roy T. Fielding wrote:
Another reason why apr_hash_t isn't a good match for HTTP headers
is that the same field name may appear multiple times in the request
or response headers (section 4.2 of RFC 2616), but the hash table
implementation is designed around unique keys.
HTTP headers were designed
Sander Striker wrote:
However, my question, and point, can't we do without
destroying all the subreqs individualy and just destroy
the request?
No can do... it's very easy to come up with a request that causes many
thousands of subrequests to be made (think mod_autoindex on a big
directory). If
Justin Erenkrantz wrote:
[...]
- Why do we want an independent per-thread SMS? Because it now removes
the requirement for locking. A thread may not be reentrant upon
itself - executing in two places at once. It's a thread with one flow
of control. Memory allocation without the need for
Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
Ian Holsman wrote:
Brian Pane wrote:
Ian Holsman wrote:
any comments on this patch?
I just read through it, and I have one major and one minor
issue:
1. Is it just my imagination, or is the overlay logic backwards?
It looks like you're making a copy of overlay and then
writing elements from
dean gaudet wrote:
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level div instruction is a two result opcode, quotient
William A. Rowe, Jr. wrote:
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Thursday, July 19, 2001 1:06 PM
I wouldn't recommend using the threaded code at all because we are still
doing a per-process allocation mutex which causes threaded to become
useless. When that is changed (i.e. we enable
Justin Erenkrantz wrote:
On Wed, Jul 25, 2001 at 10:29:35AM -0700, Brian Pane wrote:
Lately the httpd won't build when configured with
--enable-sms, because of unresolvable references to
apr_pool_child_cleanup_set in file_io/unix/open.c.
Is there supposed to be an implementation of this
function
Justin Erenkrantz wrote:
On Thu, Jul 26, 2001 at 10:50:58PM -0700, Brian Pane wrote:
But there's a problem with the SMS lock management.
According to gprof, every call to apr_sms_trivial_malloc
acquires and releases a lock.
Yup. I'm working on this right now. =) (What I have in my tree
right
Luke Kenneth Casson Leighton wrote:
On Fri, Jul 27, 2001 at 12:05:02AM -0700, Brian Pane wrote:
hmmm...looking at the code, it makes sense that SMS is
half as fast as the original pools code. I didn't realize
this until just now, but the polymorphism in the SMS framework
will probably make
David Reid wrote:
What follows is a profile for beos bone running 1000 connections using
a single thread (-DONE_PROCESS). Columns are
no. of calls
time in calls
time incl sub calls
function name
Raises some interesting questions, like how many times do we call
ap_palloc/ap_pcalloc/lock/unlock
Greg Ames wrote:
Victor J. Orlikowski wrote:
[...]
If ssi's were working, and you were measuring them, I think we would see
2.0 look a lot worse compared to 1.3, and threaded worst of all, because
we don't have a fast mutex-free replacement for malloc/free yet sigh.
For the buckets code, having
On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
like Solaris, the function get_offset in apr/time/unix/time.c is a
bottleneck in time formatting.
On these platforms, get_offset ignores its argument; it really computes
the server's offset from GMT, normalized so that it's
William A. Rowe, Jr. wrote:
From: Jeff Trawick [EMAIL PROTECTED]
Sent: Tuesday, August 28, 2001 6:47 AM
[...]
Would anybody besides me feel better if we had apr_initialize() call
apr_unix_setup_time() to do this?
Apparently :) +1
What's the right way to introduce a declaration for
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
--Brian
Index: apr/misc/unix/start.c
===
RCS
Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens
Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens
Roy T. Fielding wrote:
On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
At 10:05 AM 08/29/2001, William A Rowe wrote:
At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
As far as I can tell, the result of the calculation should
Roy T. Fielding wrote:
On Thu, Aug 30, 2001 at 01:56:13PM -0700, Justin Erenkrantz wrote:
On Wed, Aug 29, 2001 at 03:56:12PM -0700, Brian Pane wrote:
I disagree. Consider how the result of the calculation is used.
We get the offset from the current time and then plug it into the
time struct
The find_entry() function in apr_hash.c is responsible for over
half the apr_pcalloc() calls in the httpd. The calloc call
is somewhat wasteful in this context; 4 of the 5 fields in the
allocated struct get overwritten immediately. Thus the following
patch replaces the calloc with an alloc and
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!). With
this change, I'm seeing a ~3% improvement in throughput when
delivering a 0-byte file over the loopback on Linux. (I used this
0-byte test case to measure the inherent
Ryan Bloom wrote:
On Friday 07 September 2001 14:23, Brian Pane wrote:
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!). With
this change, I'm seeing a ~3% improvement in throughput when
delivering a 0-byte file over
Ryan Bloom wrote:
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.
apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses
Ryan Bloom wrote:
On Saturday 08 September 2001 15:25, Brian Pane wrote:
Ryan Bloom wrote:
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics
Justin Erenkrantz wrote:
On Sun, Sep 16, 2001 at 04:12:58PM -0700, Justin Erenkrantz wrote:
Yup. More precisely /usr/lib/lwp/libthread.so is the alternate
version and /usr/lib/libthread.so is the default version. They
are binary compatible (as far as we care) - therefore the
LD_LIBRARY_PATH
Aaron Bannert wrote:
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
On Sun, Sep 16, 2001 at 12:55:10AM -0700, Justin Erenkrantz wrote:
You also haven't mentioned how many LWPs it stabilized at after
10 seconds? Did Solaris choose to add a LWP for each user thread?
I have a
Aaron Bannert wrote:
On Mon, Sep 17, 2001 at 10:17:16AM -0700, Brian Pane wrote:
So that's 25 ThreadsPerChild + 3 builtin threads (door server, door
client, reaper) = 28, so yeah, it stabalized to the number of simultaneous
requests I expect to handle (aka the number of worker threads).
How were
Ryan Bloom wrote:
I would like to move APR to a releasable state finally. To do this, we need to
finish the locking API at the very least. Does anybody have other issues that
need to be resolved?
I have just one issue: apr_table_t
As of a couple of weeks ago, we were debating whether or not to
Greg Stein wrote:
On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
...
If not, I still would like to replace apr_table_elts with a different
interface that doesn't make any promises about apr_table_t being
an apr_array_header_t. That will enable us to fix the performance
in later
Ian Holsman wrote:
On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote:
On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
The original approach that I posted was a traditional iterator object:
typedef struct apr_table_iter_t apr_table_iter_t;
apr_table_iter_t * apr_table_iter_make
Cliff Woolley wrote:
I'm trying to decide whether apr_bucket_alloc should take a length
parameter or not. If it takes a length parameter, it can allocate in a
few different increments (say 16B, 32B, 64B, 128B), but of course it will
have to have separate free lists for each thread for each size.
Cliff Woolley wrote:
On Mon, 24 Sep 2001, Brian Pane wrote:
Is it always going to be true that all the bucket subclasses are declared
in apr_buckets.h? If so, how about doing something like this:
union bucket_size {
struct apr_bucket t1;
struct apr_bucket_heap t2;
struct apr_bucket_pool
Justin Erenkrantz wrote:
[...]
What's wrong with an internal hashtable here keyed off of the
thread id (or whatever is returned by apr_os_thread_current)?
Internally, you can represent the apr_bucket_freelist* as you
describe (that sounds good) - so we can abstract all of that
away, but forcing
I instrumented apr_pstrcat and found that, in Apache 2.0, the number of
strings it's asked to concatenate is 6 or less 99+% of the time.
apr_pstrcat does two passes through its args: one to compute the
length, a second to do the copying. This patch adds a buffer to
save the lengths of the first 6
Ryan Bloom wrote:
[...]
+static const int MAX_SAVED_LENGTHS = 6;
Why is this a static const istead of a #define?
So that its scope will be limited to the enclosing function
--Brian
Ryan Bloom wrote:
On Wednesday 26 September 2001 06:57 pm, Brian Pane wrote:
Ryan Bloom wrote:
[...]
+static const int MAX_SAVED_LENGTHS = 6;
Why is this a static const istead of a #define?
So that its scope will be limited to the enclosing function
But why is that a good thing? This should
Greg Stein wrote:
On Mon, Oct 01, 2001 at 08:28:17PM -0700, Jon Travis wrote:
On Mon, Oct 01, 2001 at 04:07:13PM -0700, Greg Stein wrote:
[...]
Personally, I'm guessing that more time is spent assembling than parsing.
Since the parsing code is intermingled with the code that throws it into
the
As we approach GA for Apache 2.0, the apr_table_t code is
one of the largest remaining performance bottlenecks. I'm
willing to spend some time fixing this, but because there
hasn't been a solid consensus when this issue has come up
in the past, I'd like to get feedback on strategy first.
I can
Greg Stein wrote:
On Sun, Nov 04, 2001 at 03:00:43PM -0800, Brian Pane wrote:
...
2. Change the performance-sensitive fields in the httpd's request_rec
from apr_table_t (like r-headers_in) to some different data type
(e.g., ap_http_headers_t) that supports O(log(n)) or O(1) get/set
The mod_mime per-dir-merge function is one of the most computationally
expensive parts of the httpd, due to all of the hash table merges that
it does. It has accounted for about 15% of the total user CPU time in
recent benchmarks.
This patch attempts to solve the problem by adding two new
Here's apdated patch with more optimizations to apr_hash_copy based
on Greg's comments on the original.
--Brian
Index: srclib/apr/include/apr_hash.h
===
RCS file: /home/cvspublic/apr/include/apr_hash.h,v
retrieving revision 1.30
diff
This patch changes the apr_table_elts macro so that it provides
access to the internals of an apr_table_t via a const pointer
instead of the current non-const pointer.
My main motivation for this is to make it possible to speed up
the table internals in the future (e.g., by adding an index
for
Justin Erenkrantz [EMAIL PROTECTED]Justin Erenkrantz wrote:
[...]
You missed a few files - namely mod_dav, mod_cgid, and proxy.
And, you didn't catch all of the instances of apr_table_entry_t
now being const (some of them were being casted to
apr_table_entry_t, so you didn't catch that they were
Cliff Woolley wrote:
On Sat, 10 Nov 2001, Brian Pane wrote:
Is anybody working on modifying mmap_setaside so that it doesn't
have to memcpy the file contents? (I recall this being an issue
a while ago.) This could yield a small but measurable improvement
on requests that aren't handled using
Cliff Woolley wrote:
On Tue, 13 Nov 2001, Brian Pane wrote:
Thanks for the pointer. Here's my attempt to work around the problem
that you noted in that message--the fact that the apr_mmap_t cleanup
function isn't accessible from within mmap_setaside. My solution was
to add a pointer
Cliff Woolley wrote:
[...]
I think the ideal situation would be if we had an apr_mmap_dup() similar
to our apr_file_dup(). apr_file_dup() already solves this problem for
files by ensuring that a duplicate copy of the file descriptor lives as
long as the given pool. apr_mmap_dup() in the case of
dean gaudet wrote:
[...]
you can always have an elt array and then use some other method to index
into the elt array...
but that sucks :)
Agreed. What I've found so far is that it's difficult to actually
improve the speed of tables if you have to update both the elt
array and an additional index.
Based on Cliff's suggestion, this patch introduces an apr_mmap_dup()
function that's used to setaside mmap buckets without having to
memcpy the content.
I gave up trying to do full reference counting semantics for
duplicates of apr_mmap_t, because I couldn't find a suitable
pool to own the locks
Cliff Woolley wrote:
[...]
The patch includes a change to mod_file_cache to create a non-owner
copy of the mmap for the bucket brigade to use, so that the mmap can't
get unmapped by any code other than mod_file_cache itself
Why is that necessary? The original mmap from mod_file_cache is owned by
Greg Stein wrote:
[...]
I gave up trying to do full reference counting semantics for
duplicates of apr_mmap_t, because I couldn't find a suitable
pool to own the locks that would be required in a threaded
implementation.
Not sure what you mean here. I don't quite understand how threading comes
This patch adds a cache to each element in an apr_table_t.
The cache consists of a 32-bit int containing the first 4 bytes
of the element's key, converted to uppercase.
This makes it possible to replace strcasecmp calls with inline
integer comparisons. If the integer comparison fails, we can skip
Cliff Woolley wrote:
On Sat, 17 Nov 2001, Brian Pane wrote:
This patch adds a cache to each element in an apr_table_t.
The cache consists of a 32-bit int containing the first 4 bytes
of the element's key, converted to uppercase.
How about something like this:
#ifndef EBCDIC
#define CASE_MASK
I wrote:
[...]
I used the more complicated, shift-based approach because it
guarantees that greater-than/less-than comparisons on the prefix
will yield the same results as strcasecmp on the first 4 bytes.
This makes it possible to use the prefix in the comparator
function in the big qsort in
Attached is a new version of my table speedup patch.
In this version, I added some additional optimizations
to the table code:
* A rewrite of apr_table_overlap() that uses a hash
table (sort of) instead of qsort
* Cliff's faster version of the prefix computation macro
* apr_palloc instead of
dean gaudet wrote:
On Sat, 17 Nov 2001, Brian Pane wrote:
* A rewrite of apr_table_overlap() that uses a hash
table (sort of) instead of qsort
i'm not sure this part of the patch is a good idea. the reason
apr_table_overlap() uses qsort is to prevent various O(n^2) DoS attacks
(both time
Mladen Turk wrote:
[...]
How about to add here something like:
(in apr_hash.h add #define APR_HASH_KEY_UCASE (-2)
+else if (klen == APR_HASH_KEY_UCASE) {
+for (p = key; *p; p++) {
+hash = hash * 33 + apr_tolower(*p);
+}
+klen = p - (const unsigned char
This patch takes advantage of the recent optimizations to
apr_hash_t's handling of APR_HASH_KEY_STRING to eliminate
a strlen call within apr_pool_userdata_set.
--Brian
Index: srclib/apr/memory/unix/apr_pools.c
===
RCS file:
patch to optimize away a big strdup at the end of apr_filepath_merge()
--Brian
Index: srclib/apr/file_io/unix/filepath.c
===
RCS file: /home/cvspublic/apr/file_io/unix/filepath.c,v
retrieving revision 1.9
diff -u -r1.9 filepath.c
---
This is a repost of my patch to speed up tables, with one change from
the previous version: the technique used to compute the checksums was
unsafe on SPARCs (doing *(int *)str where 'str' is a char* yields a
bus error if the string doesn't start on a word boundary), so I replaced
it with a
Justin Erenkrantz wrote:
[ Moving this part of the discussion to [EMAIL PROTECTED] ]
On Fri, Nov 23, 2001 at 03:16:35PM -0800, Brian Pane wrote:
Thanks. Here's my patch to optimize away the mutex operations in
pools that have been designated thread-private. With the current
worker code, it can
Doug MacEachern wrote:
does this:
end = memchr(s, '\0', n);
if (end != NULL)
n = end - s;
is that just to avoid allocating an extra byte if 's' already contains
'\0' at the end? seem like it would be better to waste the extra byte
than to scan the whole string with memchr() or at
I just tried out a simpler approach to fixing the mutex contention
within pool cleanups. It seems to work reasonably well, so I'm
presenting it here for feedback.
This patch does three things:
* Optimize away mutexes in the case of subrequest pool
deletion (an important special case because
Sander Striker wrote:
Hi,
This is my second go at the pools code.
I incorporated some suggestions made by Brian Pane.
Please review,
Sander
PS. The debug code will come back, but in a different
incarnation. I need some time to do that without
making the code unreadable.
Thanks, I'll post
Some test results, thanks to Ian H.:
http://webperf.org/a2/v30/
This compares today's httpd-2.0 CVS head with
my recycle pools patch for the worker MPM and
Sander's new implementation of pools.
Sander's pool code yielded a substantial drop
in usr CPU consumption (see the cpuu links on
the test
Justin Erenkrantz wrote:
On Tue, Dec 04, 2001 at 04:35:01PM -0800, Brian Pane wrote:
Some test results, thanks to Ian H.:
http://webperf.org/a2/v30/
This compares today's httpd-2.0 CVS head with
my recycle pools patch for the worker MPM and
Sander's new implementation of pools.
Sander's pool code
Cliff Woolley wrote:
This is my second go at the pools code.
A potential snag with the thread-specific pools idea was brought up today
when I was talking with FirstBill and some of the others. What is this
going to do to us a little ways down the road when we try to implement
async I/O, and all
Bill Stoddard wrote:
[...]
If a future async implementation has this same property--i.e.,
pools can be passed from one thread to another, but a given
pool can only have its methods invoked from one thread at a
time--then we shouldn't have any problems.
--Brian
What happens if a thread exits (under
Cliff Woolley wrote:
Okay. The situation (real or imagined) I was leery of was not allocation
but pool destruction... what happens when you have a subpool of a
one-thread-at-a-time pool that was created in one thread and gets
destroyed in another pool, if the parent pool is still active in the
Aaron Bannert wrote:
On Tue, Dec 04, 2001 at 06:56:11PM -0800, Justin Erenkrantz wrote:
[...]
2) It probably needs to be modified to use the new locking API.
I don't see this as a showstopper, but I think it's something
that should happen and may help with the locking performance.
Aaron can
Sander Striker wrote:
This is the 3rd round of the pools rewrite. This time I have gotten
rid of all tabs (grmpf) and followed some suggestions by Justin.
I'm reposting the whole file instead of a diff, since this is
the first time it is posted inline. Hopefully the interested lot
out there have
Ryan Bloom wrote:
On Thursday 06 December 2001 11:11 am, Aaron Bannert wrote:
The biggest problem is that this would change the API for the one
function that must be in every APR program.
Thoughts?
Is it the lock routine or something specific to apr_pool_init that is
creating the tmpfile? In
Sander Striker wrote:
...
*) The performance gain is in not having to walk the list of nodes in
apr_pool_clear as mentioned above. Maybe this is not really a performance
win, but more of a better devision of processing time. apr_pool_clear
and apr_pool_destroy have less work to do, this
Ian Holsman wrote:
On Fri, 2001-12-07 at 10:39, Sander Striker wrote:
...
In subversion svn_string_t was introduced, because it wasn't in APR.
It does (AFAIK) exactly what brian describes.
is there any reason NOT to introduce this into the APR now?
we could then slowly migrate strings to this
I'm
[EMAIL PROTECTED] added to the distribution list because one of
my proposed solutions is an APR enhancement]
Brad Nicholes wrote:
It appears that we are running into the same problem with Apache 2.0
that we had with Apache 1.3. The problem is recursive functions that
declare large stack
sononblock()--the function in apr/networkio/unix/sockopt.c
that puts sockets in blocking or nonblocking mode--is
responsible for a surprisingly large amount of CPU time
on Solaris. I used to think that this was inevitable, but
upon closer inspection there might be a way to fix it...
but I'd like
Ryan Bloom wrote:
On Sunday 09 December 2001 06:55 pm, Brian Pane wrote:
...
Thus the change that I'm thinking of is:
- on the first sononblock() call on a newly accepted
socket, skip the F_GETFL operation and assume that
the current flags are zero.
By my reading of the man pages
Sander Striker wrote:
Hi,
This is the code with the latest changes based on comments
from various people.
I have yet to begin to start coding/migrating the debug
code. I won't have time to complete that until at least
last week. Bill (wrowe) can you live without that for
a little while? I
Sander Striker wrote:
From: Brian Pane [ mailto:[EMAIL PROTECTED]
Sent: 10 December 2001 22:36
Sander Striker wrote:
Hi,
This is the code with the latest changes based on comments
from various people.
I have yet to begin to start coding/migrating the debug
code. I won't have time
Jeff Trawick wrote:
Brian Pane [EMAIL PROTECTED] writes:
The logic for setting the nonblocking state looks like
this:
- fcntl(sd, F_GETFL, ...) to get the current flags on
the socket descriptor
- OR the flags with O_NONBLOCK or O_NDELAY or O_FNDELAY,
depending on the OS.
- fcntl(sd
Jeff Trawick wrote:
Sander Striker [EMAIL PROTECTED] writes:
This sounds like good moment to introduce for APR_POOL_TAG.
fine by me...
One of the things that made the original pool code difficult
to maintain was that it had so many different ifdefs for
debugging. I think it would be cleaner to
About half the startup time for the httpd is spent
locking and unlocking the mutex that protects the
apr_file_t's internal buffer--even though only one
thread is using the file. This patch skips the
locking unless the APR_XTHREAD flag has been set
for the file.
--Brian
Index:
A counterpart to apr_itoa(), so that we can eliminate
some inefficient 'sprintf(foo, %u, bar)' calls in the
httpd.
Index: srclib/apr/include/apr_strings.h
===
RCS file: /home/cvspublic/apr/include/apr_strings.h,v
retrieving revision
1 - 100 of 306 matches
Mail list logo
