[EMAIL PROTECTED] wrote:
jwoolley02/05/15 16:10:52
Modified:buckets apr_buckets_file.c
Log:
file_bucket_read() is not the only caller of file_make_mmap().
file_bucket_setaside() does it as well, and that call was missed when
the can_mmap flag was added. This patch moves the can_mmap
On 11 May 2002 [EMAIL PROTECTED] wrote:
> +f->can_mmap = 1;
Great, thanks!
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Cliff Woolley wrote:
On 11 May 2002 [EMAIL PROTECTED] wrote:
brianp 02/05/11 16:10:24
Modified:.CHANGES
include apr_buckets.h
buckets apr_buckets_file.c
Log:
Added a mechanism to prevent mmap of file buckets
You need to initialize can_mmap i
On 11 May 2002 [EMAIL PROTECTED] wrote:
> brianp 02/05/11 16:10:24
>
> Modified:.CHANGES
>include apr_buckets.h
>buckets apr_buckets_file.c
> Log:
> Added a mechanism to prevent mmap of file buckets
You need to initialize can_mmap in apr_bu
On 9 Apr 2002 [EMAIL PROTECTED] wrote:
> bjh 02/04/08 20:57:47
>
> Modified:buckets apr_buckets_file.c
> Log:
> Manually created bucket needs bucket allocator field set.
> This fixes a segfault parsing large SSIs on non-mmap systems.
DOH Great catch... thanks Brian! I n
> jwoolley01/11/28 17:20:56
>
> Modified:.CHANGES
>buckets apr_buckets_file.c apr_buckets_mmap.c
> Log:
> Reading a file bucket bigger than APR_MMAP_LIMIT (4MB) now yields
> a string of 4MB mmap buckets, rather than a string of 8KB heap buckets
> plus a 4
On Tue, 27 Nov 2001, Doug MacEachern wrote:
> 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 chan
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 APR_MMAP_THRESHO
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,
On Thu, 5 Jul 2001, Roy T. Fielding wrote:
> Either define two different file bucket types or add a variable that
> indicates relative vs fixed. Fixed fds have to be seeked to the
> position of each read, whereas relative fds skip from the current
> position to the offset. File buckets are there
Either define two different file bucket types or add a variable that indicates
relative vs fixed. Fixed fds have to be seeked to the position of each read,
whereas relative fds skip from the current position to the offset. File
buckets are therefore relative until split.
Roy
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote:
> I agree, but Bill is saying that in http, we can usually count on the OS
> file offset being correct, so he wants a performance enhancement for that
> case. I have no problem adding an enhancement for that special case,
> assuming it is called out as
> > Perhaps just having a different offset, like -1 to specify that you should
> > always use the OS's file offset.
>
> Hmm... that *only* works if you can guarantee that no other code (eg, some
> filter) is going muck with the brigade. IMO you're much better off
> keeping track of the offset tha
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote:
> Perhaps just having a different offset, like -1 to specify that you should
> always use the OS's file offset.
Hmm... that *only* works if you can guarantee that no other code (eg, some
filter) is going muck with the brigade. IMO you're much better of
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> What specific problem are we trying to fix? I agree for the need for a
> seek() in the
> case you are describing below but it seems to be an unusual case, at least
> for the
> webserver. We need to focus on making APR work efficiently for the most
>
On Thu, 5 Jul 2001, Cliff Woolley wrote:
> The chunk filter.
s/chunk/byterange/
Duh.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> > > Maybe there is something very fundamental that I a missing here.
> > > Each 8K chunk that is read causes the system to increment its file
> > > pointer for that open fd. You should not need to call seek() to do
> > > something the system is already do
On Thu, 5 Jul 2001, Bill Stoddard wrote:
>
> > On Thu, 5 Jul 2001, Bill Stoddard wrote:
> >
> > > I am teetering on a -1 for this patch. You are hacking around a more
> > > fundamental problem. If we cannot fix problems like this w/o impacting
> > > the performance of all applications that need to
> > > I am teetering on a -1 for this patch. You are hacking around a more
> > > fundamental
> problem.
> > > If we cannot fix problems like this w/o impacting the performance of all
> > > applications
> that
> > > need to read files, then APR is seriously broken.
> >
> > Huh? If I have a file
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> > You can't guarantee that consecutive reads from file buckets read from the
> > "next" spot in the file. In fact, they very frequently jump around.
>
> Give me a common example of reads from file buckets jumping around.
The chunk filter. Or any filter
> > Maybe there is something very fundamental that I a missing here.
> > Each 8K chunk that is read causes the system to increment its file
> > pointer for that open fd. You should not need to call seek() to do
> > something the system is already doing for you under the covers.
>
>
>apr_file_
What specific problem are we trying to fix? I agree for the need for a seek()
in the
case you are describing below but it seems to be an unusual case, at least for
the
webserver. We need to focus on making APR work efficiently for the most common
cases and
resist the urge to create an overgene
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> Maybe there is something very fundamental that I a missing here.
> Each 8K chunk that is read causes the system to increment its file
> pointer for that open fd. You should not need to call seek() to do
> something the system is already doing for you unde
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> If you perform a read on a file and don't specifiy an offset, then you
> should assume you will be reading from the current file pointer
> maintained by the system (or by apr_file_t in the XTHREAD case). If
> you have an apr_file_t open and you are readi
> PS: The common case for this segment of code is that the offset will be
> non-zero, since it reads in from a file in 8KB hunks, incrementing the
> offset each time. So removing the conditional actually (very slightly)
> improves the performance of this section for the common case. Only the
> ca
> On Thu, 5 Jul 2001, Bill Stoddard wrote:
>
> > I am teetering on a -1 for this patch. You are hacking around a more
> > fundamental problem. If we cannot fix problems like this w/o impacting
> > the performance of all applications that need to read files, then APR
> > is seriously broken.
>
> We
> On Thu, 5 Jul 2001, Bill Stoddard wrote:
>
> > I am teetering on a -1 for this patch. You are hacking around a more
> > fundamental
problem.
> > If we cannot fix problems like this w/o impacting the performance of all
> > applications
that
> > need to read files, then APR is seriously broken.
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> I am teetering on a -1 for this patch. You are hacking around a more
> fundamental problem. If we cannot fix problems like this w/o impacting
> the performance of all applications that need to read files, then APR
> is seriously broken.
Well, that's prob
On Thu, 5 Jul 2001, Bill Stoddard wrote:
> I am teetering on a -1 for this patch. You are hacking around a more
> fundamental problem.
> If we cannot fix problems like this w/o impacting the performance of all
> applications that
> need to read files, then APR is seriously broken.
Huh? If I ha
gt;
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 8:58 PM
Subject: cvs commit: apr-util/buckets apr_buckets_file.c
> rbb 01/07/04 17:58:56
>
> Modified:buckets apr_buckets_file.c
> Log:
> We need to ALWAYS do the seek if we are reading from the fil
On Wed, 4 Jul 2001 [EMAIL PROTECTED] wrote:
> > H... good catch. I don't know why I never thought of that before.
> > You're right that it sucks for performance, but then again if we
> > get to this point we've given up on mmaping the file so we're in the
> > "worst case" performance scenar
> > We need to ALWAYS do the seek if we are reading from the file. This is
> > unfortunate from a performance perspective, but right now, I can have an
> > offset of 0 in the bucket, but be referring to a file that has been read
> > from. If we don't seek before reading from the bucket,
On 5 Jul 2001 [EMAIL PROTECTED] wrote:
> We need to ALWAYS do the seek if we are reading from the file. This is
> unfortunate from a performance perspective, but right now, I can have an
> offset of 0 in the bucket, but be referring to a file that has been read
> from. If we don't seek b
+1
Ryan
On Fri, 16 Feb 2001, Cliff Woolley wrote:
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > This was just committed to apr_util's bucket code. This should fix the
> > mod_include problem (at least it did for me). What was happening, was
> > t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> This was just committed to apr_util's bucket code. This should fix the
> mod_include problem (at least it did for me). What was happening, was
> that we read from the file, and converted it into a heap bucket. Th
35 matches
Mail list logo
