Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <002e01c663ae$949b68b0$6700a8c0@binarysecfb111>
From: "Michael Vergoz" <mv@binarysec.com>
To: "Joe Orton" <jorton@redhat.com>, "Tyler MacDonald" <tyler@yi.org>
Cc: <dev@apr.apache.org>
References: <20060418203953.GW25538@yi.org>
 <20060419104138.GB15852@redhat.com>
Subject: Re: Shared memory segment management
Date: Wed, 19 Apr 2006 14:41:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

> IIRC the logic for choice of name-based shm implementation for APR does
> exactly match that of MM - is that not true?  I don't know why shmget is
> preferred over mmap in this case.  For anonymous shm, mmap/MAP_ANON is
> indeed preferred over shmget, which does seem inconsistent.

For me an MAP_SHARED used with MAP_ANON isn't correct because an SHM should 
be used to sync a file and a memory. Perhaps i am wrong..

But it isn't recommended to use MAP_FIXED (i.e: manpage) in general. How can 
process A know the SHM start address of process B ? with a pipe ? that is 
dirty. The sys ipc implementation is also not correct and there is something 
you can't do like remapping.

I have made a small implementation of a new SHM design :
http://www.badcode.be/~descript/.apache/

FEATURES:
- "pager" allows you to specify a multiple of pages that may be used. It 
reduces reallocation so it reduces kernel call.
- Memory auto alignement
- File map auto padding
- Auto remove on bad header
- Auto create if file doesn't exist
- Remap/reallocation possibility.
- Auto padding (mem/file) when reallocating.
- Kernel lock/unlock.
- Memory bridge capatibility.
- 2 lock types.

This implementation was stoped because Apache folks have not been interested 
by this code (this is probably because the code isn't "apr ready")

-mv