You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by rb...@apache.org on 2001/08/14 07:15:00 UTC
cvs commit: apr CHANGES configure.in
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:
Revision Changes Path
1.138 +8 -0 apr/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apr/CHANGES,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- CHANGES 2001/08/13 21:49:08 1.137
+++ CHANGES 2001/08/14 05:14:59 1.138
@@ -1,5 +1,13 @@
Changes with APR b1
+ *) 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.
+ [Ryan Bloom]
+
*) Move the necessary shared memory code from MM into APR and remove
our dependency upon MM. [Justin Erenkrantz]
1.357 +12 -12 apr/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.356
retrieving revision 1.357
diff -u -r1.356 -r1.357
--- configure.in 2001/08/13 21:49:08 1.356
+++ configure.in 2001/08/14 05:14:59 1.357
@@ -394,22 +394,22 @@
dnl Now we determine which one is our preference.
APR_BEGIN_DECISION([shared memory allocation method])
-APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
- APR_DECIDE(USE_SHMEM_MMAP_TMP,
- [Classical mmap() on temporary file]))
+APR_IFALLYES(header:sys/mman.h func:mmap func:munmap define:MAP_ANON,
+ APR_DECIDE(USE_SHMEM_MMAP_ANON,
+ [4.4BSD-style mmap() via MAP_ANON]))
+APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
+ func:shmget func:shmat func:shmdt func:shmctl,
+ APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()]))
+APR_IFALLYES(header:sys/mman.h func:mmap func:munmap file:/dev/zero,
+ APR_DECIDE(USE_SHMEM_MMAP_ZERO,
+ [SVR4-style mmap() on /dev/zero]))
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap func:shm_open dnl
func:shm_unlink,
APR_DECIDE(USE_SHMEM_MMAP_SHM,
[mmap() via POSIX.1 shm_open() on temporary file]))
-APR_IFALLYES(header:sys/mman.h func:mmap func:munmap file:/dev/zero,
- APR_DECIDE(USE_SHMEM_MMAP_ZERO,
- [SVR4-style mmap() on /dev/zero]))
-APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
- func:shmget func:shmat func:shmdt func:shmctl,
- APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()]))
-APR_IFALLYES(header:sys/mman.h func:mmap func:munmap define:MAP_ANON,
- APR_DECIDE(USE_SHMEM_MMAP_ANON,
- [4.4BSD-style mmap() via MAP_ANON]))
+APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
+ APR_DECIDE(USE_SHMEM_MMAP_TMP,
+ [Classical mmap() on temporary file]))
APR_IFALLYES(header:kernel/OS.h func:create_area,
APR_DECIDE(USE_SHMEM_BEOS, [BeOS areas]))
APR_END_DECISION
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
--------------------------------------------------------------
Re: cvs commit: apr CHANGES configure.in
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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