From 99426172cc1bbbd92d2aacd405ae0935ed37b0aa Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Sat, 22 Sep 2001 01:37:47 +0000 Subject: Add recent developments. --- winsup/cygwin/how-cygheap-works.txt | 38 ++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/winsup/cygwin/how-cygheap-works.txt b/winsup/cygwin/how-cygheap-works.txt index ab4131d2b..53bd55d65 100644 --- a/winsup/cygwin/how-cygheap-works.txt +++ b/winsup/cygwin/how-cygheap-works.txt @@ -91,14 +91,30 @@ Previously, we let the "OS" choose where to allocate the cygwin heap in the initial cygwin process and attempted to use this same location in subsequent cygwin processes started from this parent. -This was basically done to accomodate Windows XP, although there were -sporadic complaints of cygwin heap failures in other pathological -situations with both NT and 9x. In Windows XP, Microsoft made the -allocation of memory less deterministic. This is certainly their right. -Cygwin was previously relying on undocumented and "iffy" behavior before. - -We're not exactly on completely firm ground now, though. We are assuming -that there is sufficient space after the cygwin DLL for the allocation -of the cygwin heap. So far this assumption has proved workable but there -is no guarantee that newer versions of Windows won't break this assumption -too. +The reason for putting cygheap at a fixed, known location is that we +need to put this information at a fixed location since it incorporates +pointers to entities within itself. So, when a process forks or execs, +the memory referred to by the pointers has to exist at the same place in +both the parent or the child. + +(It "might be nice" to used something like Microsoft's "based pointers" +for the cygheap. Unfortunately gcc does not support that feature, as of +this writing.) + +The reason for choosing a fixed, arbitrary location is to accomodate +Windows XP, although there were sporadic complaints of cygwin heap +failures in other pathological situations with both NT and 9x. In +Windows XP, Microsoft made the allocation of memory less deterministic. +This is certainly their right. Cygwin was previously relying on +undocumented and "iffy" behavior before. So, now we always allocate +space immediately after the dll in the theory that there is not going +to be anything else living there. + +Recent (2001-09-20) cygwin email threads have indicated that we're not +exactly on completely firm ground now, though. We are assuming that +there is sufficient space after the cygwin DLL for the allocation of the +cygwin heap. Unfortunately the ld option '--enable-auto-image-base' +has a tendency to allocate DLLs immediately after cygwin1.dll. This +causes the dreaded "Couldn't reserve space for cygwin's heap" message. + +Solutions for this behavior are currently in the musing state. -- cgit v1.2.3