You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/08/14 07:54:05 UTC
Re: cvs commit: apr CHANGES configure.in
On Tue, Aug 14, 2001 at 05:15:00AM -0000, rbb@apache.org wrote:
> rbb 01/08/13 22:15:00
>
> Modified: . CHANGES configure.in
> Log:
> Fix the new shared memory configure script. The APR_DECIDE
> macros go in order, so the last set of dependancies that are
> met are the ones used. That means that when using those macros,
> options should be listed with the least desirable option first,
> and the most desirable last. The new shared memory routines did
> the opposite, so we chose the wrong shared memory option on Linux.
> CS: Obtained from:
Eh, what?
Don't we want to avoid MMAP on a temporary file? This seems contrary
to how I understand things. Now, we have to have enough disk space
to back the shared memory. Ack.
The ordering was as I intended and is similar to the ordering in MM.
MAP_ANON should be our preference on Linux. There are some reports
that older versions of Linux don't support MAP_ANON properly. But,
I haven't run across that yet. -- justin
Re: cvs commit: apr CHANGES configure.in
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 13 August 2001 23:17, Justin Erenkrantz wrote:
> On Mon, Aug 13, 2001 at 11:03:50PM -0700, Ryan Bloom wrote:
> > Well, looking at MM, it decides to use IPCSHM on my linux box. I was
> > unable to make my machine work when using MAP_ANON. I also looked at
> > what we did for Apache-1.3. We used SHMGET for Linux on 1.3.
> >
> > This makes me think we should be using SHMGET on linux. I just did what
> > I needed to, to get Linux up and running again. If you can make MAP_ANON
> > work, great. Otherwise, for right now, we have a working server. :-)
>
> Ah, Mandrake 7.2, right? Linux 2.2-based... Aha.
>
> I wonder if they fixed MAP_ANON in Linux 2.4. MAP_ANON worked fine
> with a 2.4 series kernel. So, we could add an override for <2.4 (what
> about 2.3?) to not use MAP_ANON. I wonder why SHMGET wasn't working -
> it worked fine on Solaris (so the code should supposedly work on Linux).
>
> Wouldn't /dev/zero be a better choice than a temporary file? I think
> even 2.2 has support for that.
>
> I'll try testing with a Linux 2.2 machine (hopefully soon). If I can
> figure out the right way to avoid using MAP_ANON in 2.2 (or other
> brokenness), I'll revert to the previous order with appropriate
> safeguards. -- justin
Okay, sounds good. As for the options other than MMAP_TMP, I didn't
really do a lot of testing. I removed as many warnings as I could, and just
tried to figure out what you were trying to do with the configure script.
Obviously, I got it completely wrong. :-)
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: apr CHANGES configure.in
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Aug 13, 2001 at 11:03:50PM -0700, Ryan Bloom wrote:
> Well, looking at MM, it decides to use IPCSHM on my linux box. I was unable
> to make my machine work when using MAP_ANON. I also looked at what we
> did for Apache-1.3. We used SHMGET for Linux on 1.3.
>
> This makes me think we should be using SHMGET on linux. I just did what I
> needed to, to get Linux up and running again. If you can make MAP_ANON
> work, great. Otherwise, for right now, we have a working server. :-)
Ah, Mandrake 7.2, right? Linux 2.2-based... Aha.
I wonder if they fixed MAP_ANON in Linux 2.4. MAP_ANON worked fine
with a 2.4 series kernel. So, we could add an override for <2.4 (what
about 2.3?) to not use MAP_ANON. I wonder why SHMGET wasn't working -
it worked fine on Solaris (so the code should supposedly work on Linux).
Wouldn't /dev/zero be a better choice than a temporary file? I think
even 2.2 has support for that.
I'll try testing with a Linux 2.2 machine (hopefully soon). If I can
figure out the right way to avoid using MAP_ANON in 2.2 (or other
brokenness), I'll revert to the previous order with appropriate
safeguards. -- justin
Re: cvs commit: apr CHANGES configure.in
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 13 August 2001 22:54, Justin Erenkrantz wrote:
> On Tue, Aug 14, 2001 at 05:15:00AM -0000, rbb@apache.org wrote:
> > rbb 01/08/13 22:15:00
> >
> > Modified: . CHANGES configure.in
> > Log:
> > Fix the new shared memory configure script. The APR_DECIDE
> > macros go in order, so the last set of dependancies that are
> > met are the ones used. That means that when using those macros,
> > options should be listed with the least desirable option first,
> > and the most desirable last. The new shared memory routines did
> > the opposite, so we chose the wrong shared memory option on Linux.
> > CS: Obtained from:
>
> Eh, what?
>
> Don't we want to avoid MMAP on a temporary file? This seems contrary
> to how I understand things. Now, we have to have enough disk space
> to back the shared memory. Ack.
>
> The ordering was as I intended and is similar to the ordering in MM.
> MAP_ANON should be our preference on Linux. There are some reports
> that older versions of Linux don't support MAP_ANON properly. But,
> I haven't run across that yet. -- justin
Well, looking at MM, it decides to use IPCSHM on my linux box. I was unable
to make my machine work when using MAP_ANON. I also looked at what we
did for Apache-1.3. We used SHMGET for Linux on 1.3.
This makes me think we should be using SHMGET on linux. I just did what I
needed to, to get Linux up and running again. If you can make MAP_ANON
work, great. Otherwise, for right now, we have a working server. :-)
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------