Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Tue, 4 Jan 2000 18:40:35 -0500 Message-Id: <200001042340.SAA26858@envy.delorie.com> From: DJ Delorie To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: "kernel" heap idea Many unixes have a set of functions that function like malloc/realloc/free, but use the kernel's memory heap instead of the application's heap. With Cygwin, such a feature could be used to manage a chunk of shared memory instead of hard-coding items into the existing shared memory area. This would especially be useful for cases where the number of items is variable (like delqueue). While reading up on how to do this under Win32, I did notice two shortcomings: * NT doesn't guarantee that a given virtual memory range will be available for the next cygwin program, so the shared memory region may not be able to be mapped in the same place for each invocation of the dll. I don't think this will be much of a problem for most apps, as the cygwin dll gets to initialize itself pretty early, but we may want a way to let the user pick a different address (perhaps through the tunable parameter idea I posted earlier) to avoid conflict with other allocations. * Win32 doesn't let you expand a shared memory region once you've created it, so if we run out of memory in that region, we're out. Again, this may be a case where a tunable parameter is the right way to deal with this, and we'd need to be careful with functions that use the shared area to make sure they return the right errors if it runs out. I don't think either of these are real show-stoppers as long as we don't get carried away with what we put in the shared area. Comments?