Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Wed, 5 Jan 2000 16:37:19 -0500
From: Chris Faylor <cgf AT cygnus DOT com>
To: DJ Delorie <dj AT delorie DOT com>
Cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: "kernel" heap idea
Message-ID: <20000105163719.A5354@cygnus.com>
Mail-Followup-To: DJ Delorie <dj AT delorie DOT com>,
	cygwin-developers AT sourceware DOT cygnus DOT com
References: <200001042340 DOT SAA26858 AT envy DOT delorie DOT com> <20000104185725 DOT A1605 AT cygnus DOT com> <200001050001 DOT TAA27045 AT envy DOT delorie DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200001050001.TAA27045@envy.delorie.com>; from dj@delorie.com on Tue, Jan 04, 2000 at 07:01:29PM -0500

On Tue, Jan 04, 2000 at 07:01:29PM -0500, DJ Delorie wrote:
>> We rely on the fact that memory is available at the same location for
>> fork so if this breaks we have serious problems anyway.
>
>OK.  I didn't think this would be a problem, but the documentation
>does specifically state that you can't rely on it.  I assumed that if
>we did the allocation near program startup, we'd be able to get the
>same spot each time.

This is apparently, true.  I hate relying on behavior that is documented
to be uncertain but we don't have much choice, it seems.

>> Also, as long as the memory doesn't contain internal references to
>> itself, you could get by with relocation.
>
>Not if it's shared.  Relocating for one app would break the others.

The usual way of dealing with this is to avoid having pointers in the
shared memory region.  Instead you use offsets from the base of the
shared memory.

>> It doesn't let you expand a region but you can use the same mechanism
>> as we do for the heap where you set aside a region but don't really
>> allocate it.
>
>Is that the option for non-committed mappings, with VirtualAlloc later?

I was thinking of the SEC_RESERVE option to CreateFileMapping().

>> I think that we could generalize the malloc in newlib to handle
>> multiple heaps.
>
>We'd have to be careful not to break other newlib-using tools.

Yeah.  Maybe it's time for our own version of malloc...

cgf