Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Tue, 4 Jan 2000 19:01:29 -0500 Message-Id: <200001050001.TAA27045@envy.delorie.com> From: DJ Delorie To: cgf AT cygnus DOT com CC: cygwin-developers AT sourceware DOT cygnus DOT com In-reply-to: <20000104185725.A1605@cygnus.com> (message from Chris Faylor on Tue, 4 Jan 2000 18:57:25 -0500) Subject: Re: "kernel" heap idea References: <200001042340 DOT SAA26858 AT envy DOT delorie DOT com> <20000104185725 DOT A1605 AT cygnus DOT com> > 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. > 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. > 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? > If we are going to be inventing some kind of malloc-like allocation > in cygwin, it would be nice (tm) to also have a completely separate > malloc heap for cygwin itself. You mean a per-process cygwin-private heap? In addition to the global shared heap? Hmmm... > 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.