This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: The cygheap saga
At 10:01 PM 4/3/2004 -0500, Christopher Faylor wrote:
>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.
Sure.
>>>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
>>unproven).
>
>You keep decrementing from alloc_sz until you hit cygheap_max then you punt.
... and after each decrement you call VirtualAlloc
Isn't it better finding out in one shot how much you can get?
>No, it's not for this weekend. Brian Ford only asked for some debugging
>of the problem *yesterday*.
>
>Thanks, Brian, btw.
One suggestion: Try calling GetModuleFileName to find out where the interferer
is coming from.
Pierre