Re: The cygheap saga

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

At 10:37 PM 4/1/2004 -0500, Christopher Faylor wrote:
>On Thu, Apr 01, 2004 at 09:36:14PM -0500, Pierre A. Humblet wrote:
>>At 06:11 PM 4/1/2004 +0200, Corinna Vinschen wrote:
>>>
>>>AFAICS, we have currently three pressing problems:
>>>
>>>- People complaining about cygheap problems (Win32 error 487) but
>>>  nobody willing to debug it.
>>
>>I will describe how it works (details in how-cygheap-works),
>>and then how we might change that to improve the chance of
>>success.
>>
>>1) When starting, Cygwin tries to reserve an amount of memory Pr
>>   as large as possible with CYGHEAPSIZE >= Pr >= CYGHEAPSIZE_MIN
>>   The initial committed memory size Pc is 0.
>>2) As Cygwin operates and calls csbrk , Pc grows. Pc can grow
>>   past Pr, although that is unlikely, and in fact impossible if
>>   Pr <  CYGHEAPSIZE. csbrk calls will not fail as long as Pc <= Pr.
>>3) When starting a child, the parent creates a file mapping of size 
>>   Max(Pc, Pr), copies Pc bytes to it and passes the handle to the child.
>>4) The child tries to map the region to the same address as the parent's
>>   heap. If that works, the child is done.
>>5) Else the child tries to reserve Max(Pc, Pr) at the same address
>>   as the parent's heap.
>>6) The child then commits and copies Pc bytes from the file mapping to
>>   that region.
>>The failure occurs in step 5.
>>
>>What I don't see if why we need to reserve Max(Pc, Pr) and not simply
>>a quantity Cr with Pr >= Cr >= Pc or Pr >= Cr >= max(Pc, CYGHEAPSIZE_MIN).
>>We could even try to make Cr as large as CYGHEAPSIZE, but if the parent
>>did not succeed I would think the child won't either.
>>As an aside, I am wondering if the current step 5 can ever work (on NT)
>>if step 4 has failed. Why would 4 fail if space is available? 
>
>Let me make it really simple.
>
>Parent is reserving X amount of space.
>
>Child can't reserve that much space because something (probably a DLL)
>is blocking the reservation of the full amount of space.
>
>Before we change the design, we need to find out what is blocking the
>reservation of the memory rather than just making the child allocate less
>space than the parent.

Why not do both, given that this problem seems to pop up regularly?
At any rate I had written a patch and I tested on NT today (on a machine 
without problem). The curious can try it. It's a fairly simple patch.

Pierre

Attachment: cygheap.cc.diff
Description: Text document