Mail Archives: cygwin-developers/2000/01/05/16:35:23
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
- Raw text -