From 128f2650a5323f955322ed54f880a35d2c78ee46 Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Thu, 6 Sep 2001 16:53:48 +0000 Subject: [PATCH] Another in the how-it-works series. --- winsup/cygwin/how-cygheap-works.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 winsup/cygwin/how-cygheap-works.txt diff --git a/winsup/cygwin/how-cygheap-works.txt b/winsup/cygwin/how-cygheap-works.txt new file mode 100644 index 000000000..c60cdc340 --- /dev/null +++ b/winsup/cygwin/how-cygheap-works.txt @@ -0,0 +1,22 @@ +[Not yet complete] +Cygwin has recently adopted something called the "cygwin heap". This is +an internal heap that is inherited by forked/execed children. It +consists of process specific information that should be inherited. So +things like the file descriptor table, the current working directory, +and the chroot value live there. + +The cygheap is also used to pass argv information to a child process. +There is a problem here, though. If you allocate space for argv on the +heap and then exec a process the child process (1) will happily use the +space in the heap. But what happens when that process execs another +process (2)? The space used by child process (1) still is being used in +child process (2) but it is basically just a memory leak. + +To rectify this problem, memory used by child process 1 is tagged in +such a way that child process 2 will know to delete it. This is in +cygheap_fixup_in_child. + +The cygheap memory allocation functions are adapted from memory +allocators developed by DJ Delorie. They are similar to early BSD +malloc and are intended to be relatively lightweight and relatively +fast.