The cygheap saga

Christopher Faylor
Sun Apr 4 03:31:00 GMT 2004

On Sat, Apr 03, 2004 at 09:37:47PM -0500, Pierre A. Humblet wrote:
>At 12:18 PM 4/3/2004 -0500, Christopher Faylor wrote:
>>I wonder if cygheap should just be using techniques similar to fork and
>>avoiding the use of shared memory.  The shared memory implementation was
>>a noble experiment on my part.  IIRC, ReadProcessMemory actually turned
>>out to be faster than using shared memory.
>That may be faster but in absence of the "other thing" below, how does that
>solve the problem of making sure that the heap address is  available in the
>child?  Also wouldn't that force the long synchronization method where the
>child must start suspended?

Why would this be any more necessary than for fork?  The parent is already
waiting for the child in some way whether it's fork or exec.  For the fork
case you could even subsume the copying into the fork_copy operation.

>>The other thing I'd *really* like to do is somehow construct the DLL such
>>that the N bytes of the cygheap are automatically reserved by the loader.
>>I can't tell if this is impossible to do in PE format/Windows or if it's
>>just not possible to do with GNU ld.

I don't think Microsoft's (or linux's for that matter) linker allows this.

>>If we could do that, it would probably eliminate many of the problems with
>>If we need to minimize the amount of memory used in the child, we probably
>>should generalize the routine currently used in init_cheap.
>Do you mean decremending by 2 MB until it works? That's what I initially 
>thought too (see my original message above), but when I started writing code
>I changed my mind. One needs to pass more parameters to the child and I
>doubt that calling VirtualAlloc many times until success is faster than
>calling VirtualQuery once (assuming that idea works, which is still

You keep decrementing from alloc_sz until you hit cygheap_max then you punt.

>>I do want to find out what's going on with people reporting this problem
>>before I commit YA workaround, though.
>OK. It looks like 1.5.10 is not for this weekend.

No, it's not for this weekend.  Brian Ford only asked for some debugging
of the problem *yesterday*.

Thanks, Brian, btw.


More information about the Cygwin-developers mailing list