On 27 Nov 2001 [EMAIL PROTECTED] wrote:
dougm 01/11/27 15:50:47
Modified:include apr_mmap.h
buckets apr_buckets_file.c
Log:
move MMAP_{THRESHOLD,LIMIT} defines to apr_mmap.h so they can be
used elsewhere
+1 on concept, but if you're going to do this, the
On Tue, 27 Nov 2001, Cliff Woolley wrote:
+1 on concept, but if you're going to do this, the things need APR_
namespace protection.
ok, wasn't sure if those values might already be defined in a system
header file. if so, then i'll change to:
#ifdef MMAP_THXéRæOLD
# define
On Tue, 27 Nov 2001, Cliff Woolley wrote:
It's theoretically possible for it to happen if you've split or copied
your file bucket _before reading from it_ the first time.
Nope, scratch that, it won't even happen in that case. Duh. The
split/copied file buckets point to the _same_
On Tue, 27 Nov 2001, Cliff Woolley wrote:
Nope, scratch that, it won't even happen in that case. Duh. The
split/copied file buckets point to the _same_ apr_bucket_file struct and
therefore the _same_ apr_file_t. Only once will we ever see that
apr_file_t as APR_XTHREAD, at which point we
On Tue, 27 Nov 2001, Doug MacEachern wrote:
main issue for me is, if the file cannot be mmapped, i want to avoid
apr_bucket_read()/file_read() and just call apr_file_read() directly for
better performance. i imagine other modules might want to do this as
well. wouldn't want to see
the specific case i'm looking at now is mod_ssl.
if the filelength is 4Mb, performance really blows chunks. calling
apr_file_read (or xread) directly instead of apr_bucket_read() would
improve things a great deal.
From: Doug MacEachern [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 8:09 PM
the specific case i'm looking at now is mod_ssl.
if the filelength is 4Mb, performance really blows chunks. calling
apr_file_read (or xread) directly instead of apr_bucket_read() would
improve things a great
On Tuesday 27 November 2001 07:02 pm, Doug MacEachern wrote:
This seems straightforward to me. The bucket read function doesn't
make sense in this case, because we know that we are going to read
the entire file, and throw all of it away without ever actually using the
data once it has been
From: Ryan Bloom [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 9:12 PM
On Tuesday 27 November 2001 07:02 pm, Doug MacEachern wrote:
This seems straightforward to me. The bucket read function doesn't
make sense in this case, because we know that we are going to read
the entire file,
- Original Message -
From: Barry Pederson [EMAIL PROTECTED]
To: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 9:12 PM
Subject: Re: APR Win32 file_io bug/problem
William A. Rowe, Jr. wrote:
Given what you've said though, it looks like the OS/2
From: Cliff Woolley [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 9:35 PM
Well, here's another kludge for you: the problem is that apr_bucket_read()
for file buckets falls into an abyss of performance as soon as the magic
APR_MMAP_LIMIT is exceeded. That's because we give up on mmap
On Tue, 27 Nov 2001, William A. Rowe, Jr. wrote:
Better yet.
If APR_MMAP_LIMIT is exceeded, break it into n APR_MMAP_LIMIT sized buckets,
wherein only one bucket may be mapped at a time.
What I'm suggesting is that as each bucket is consumed, it is un-memaped.
The buckets are only mmaped as
On Tue, 27 Nov 2001, Cliff Woolley wrote:
APR_MMAP_LIMIT is exceeded. That's because we give up on mmap entirely
and read 8kb at a time frome the whole bigass file, even if all we wanted
in the first place was the first 32 bytes or so (say for something like
mod_mime_magic) and we're never
On Tuesday 27 November 2001 08:05 pm, William A. Rowe, Jr. wrote:
From: Cliff Woolley [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 9:35 PM
Well, here's another kludge for you: the problem is that
apr_bucket_read() for file buckets falls into an abyss of performance as
soon as the
On Tue, 27 Nov 2001, Ryan Bloom wrote:
Not good. The problem is that you will take the real chance that multiple
filters will be converting to mmap, and then unmapping large files without
making any changes. Think of a large SSI file that does have any tags.
You'll MMAP each piece,
On Tuesday 27 November 2001 09:26 pm, Cliff Woolley wrote:
On Tue, 27 Nov 2001, Ryan Bloom wrote:
Not good. The problem is that you will take the real chance that
multiple filters will be converting to mmap, and then unmapping large
files without making any changes. Think of a large SSI
On Tue, 27 Nov 2001, Ryan Bloom wrote:
Bill's idea was to map and then unmap the individual sections of the
file, so that no more than one section was mapped at a time. If you
do that, and you really unmap each section as you map the next, you
will be thrashing your MMAPs. If you are really
On Tuesday 27 November 2001 09:39 pm, Cliff Woolley wrote:
On Tue, 27 Nov 2001, Ryan Bloom wrote:
Bill's idea was to map and then unmap the individual sections of the
file, so that no more than one section was mapped at a time. If you
do that, and you really unmap each section as you map
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
Brian Pane [EMAIL PROTECTED] writes:
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
Ian Holsman [EMAIL PROTECTED] writes:
(inline as well as attached)
This is my first foray into AutoConf.. so this is why I'm posting the patch
it defines there new #defines APU_HAVE_XDBM.
there is also a new dbm open function _open_ex(...) to specify the DBM
later all also add a specific
Jeff Trawick wrote:
Subject:
Re: Mutli-DBM patch
From:
Jeff Trawick [EMAIL PROTECTED]
Date:
28 Nov 2001 08:32:14 -0500
To:
Ian Holsman [EMAIL PROTECTED]
CC:
dev@apr.apache.org
Ian Holsman [EMAIL PROTECTED] writes:
(inline as well as attached)
This is my first foray into AutoConf.. so this is why
22 matches
Mail list logo
