On Thu, Feb 28, 2002 at 12:00:16PM -0800, Greg Stein wrote:
[ moved from [EMAIL PROTECTED] mailing list ]
On Thu, Feb 28, 2002 at 09:21:36AM -0800, Justin Erenkrantz wrote:
...
This shouldn't be too much of a problem because BDB will try to
hide that, but APR will *not* handle large files
At 02:00 PM 2/28/2002, Greg Stein wrote:
On Thu, Feb 28, 2002 at 09:21:36AM -0800, Justin Erenkrantz wrote:
...
This shouldn't be too much of a problem because BDB will try to
hide that, but APR will *not* handle large files on Linux since
they disable sendfile() with 64bit files. Since APR is
Just thought I'd quip up and show what I've had working for me re:
largefiles on Solaris with sendfilev. See the patch attached to this mail.
Everything seems to work fine. I can serve 2GB files and write logs past
the 2GB mark as well. Running 'nm' on libapr.so and httpd show all the
necessary
Well, it's not finished yet, but it's something you can look at if you
like. http://icarus.apache.org/~jwoolley/ .
Things missing:
(a) calls to apr_bucket_alloc_create() and _destroy() at strategic
locations within the MPMs. I'm hoping that's something one of you guys
can help me with, since
On Thu, Feb 28, 2002 at 10:20:15PM -0800, Brian Pane wrote:
We saw this with the SMS allocators last year. SMS had a great design:
a family of interchangeable allocators with different memory management
implementations, and an single, abstract interface to all of them so that
one could easily
Cliff Woolley wrote:
Well, it's not finished yet, but it's something you can look at if you
like. http://icarus.apache.org/~jwoolley/ .
Things missing:
(a) calls to apr_bucket_alloc_create() and _destroy() at strategic
locations within the MPMs. I'm hoping that's something one of you guys
can
Jeff Trawick [EMAIL PROTECTED] writes:
Aaron Bannert [EMAIL PROTECTED] writes:
Could this be what's causing the SIGBUS? My current theory is that
there's a size mismatch betwen ws-conn_bytes (an apr_off_t) and
the (unsigned long) that only shows up on word-alignment-picky
chips like
Jeff Trawick [EMAIL PROTECTED] writes:
This patch gets me running again:
Index: srclib/apr/shmem/unix/shm.c
===
RCS file: /home/cvs/apr/shmem/unix/shm.c,v
retrieving revision 1.14
diff -u -r1.14 shm.c
---
I've still got sleep in my eyes, so I might not be seeing this correctly
yet, but isn't the problem not that the segment itself is misaligned,
but that the structure that is being placed over that segment not
properly padded to account for alignment?
This looks like the problem to me:
Aaron Bannert [EMAIL PROTECTED] writes:
I've still got sleep in my eyes, so I might not be seeing this correctly
yet, but isn't the problem not that the segment itself is misaligned,
but that the structure that is being placed over that segment not
properly padded to account for alignment?
On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote:
I'll punt for the moment on whether or not that code is bad. The
shared memory code definitely needs to be fixed. Look at this simple
test of alignment:
#include stddef.h
#include stdio.h
int main(void)
{
struct s1 {
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Yes, I completely agree that each structure needs to be 64-bit aligned.
I don't see how the shared memory code itself is incorrect. It must be
mapping the segment at a properly aligned boundary, so as long as the
contents of that segment are accessed
Aaron Bannert [EMAIL PROTECTED] writes:
On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote:
printf(%d %d %d %d\n,
offsetof(struct s1,b),
offsetof(struct s2,b),
offsetof(struct s3,b),
offsetof(struct s4,b));
s3 =
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Yes, I completely agree that each structure needs to be 64-bit aligned.
I don't see how the shared memory code itself is incorrect. It must be
mapping the segment at a properly aligned boundary, so as long
On Fri, Mar 01, 2002 at 01:37:27PM -0500, Jeff Trawick wrote:
Yes, I completely agree that each structure needs to be 64-bit aligned.
I don't see how the shared memory code itself is incorrect.
It is incorrect because it is returning addresses that aren't 64-bit
aligned.
This code is in
On 1 Mar 2002, Jeff Trawick wrote:
Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns
addresses which aren't 64-bit aligned. That is broken. End of story.
Yeah, your last message cleared a lot up. Thanks. But I believe we're
all right. Both things are broken. :)
--Cliff
Cliff Woolley [EMAIL PROTECTED] writes:
On 1 Mar 2002, Jeff Trawick wrote:
Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns
addresses which aren't 64-bit aligned. That is broken. End of story.
Yeah, your last message cleared a lot up. Thanks. But I believe we're
all
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Can we put that alignment macro in a common place in APR, since it
is not useful to apps and internals?
s/not/now/, right? :)
Does this look right? (attached to avoid line wrapping)
--
On Fri, 1 Mar 2002, Cliff Woolley wrote:
Does this look right? (attached to avoid line wrapping)
Hmm, no, it doesn't. :-/ Scratch that. Back to the drawing board.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Can we put that alignment macro in a common place in APR, since it
is not useful to apps and internals?
but where :) apr_lib.h? (duck)
Does this look right? (attached to avoid line wrapping)
that is how I
Cliff Woolley wrote:
Well, it's not finished yet, but it's something you can look at if you
like. http://icarus.apache.org/~jwoolley/ .
Things missing:
(a) calls to apr_bucket_alloc_create() and _destroy() at strategic
locations within the MPMs. I'm hoping that's something one of
21 matches
Mail list logo
