[lug] comparing libc and the DLL runtime lib in windows

D. Stimits stimits at comcast.net
Tue Apr 12 12:47:28 MDT 2005


Jordan Crouse wrote:
>  >>Btw, maybe you could clear up something up for me: Is there a libc.so
>  >>(an equivalent to the DLL runtime library in windows) or doesn't linux
>  >>have the multiple heaps problem at all ?
>  >
>  >
>  > Obviously libc is shared, but I'm not quite sure what he means by the
>  > "multiple heaps problem" in his question.
> 
> Total shot from left field, but it seems he is lamenting that variables 
> cannot be shared between processes. In other words, each process has its 
> own memory space, possibly resulting in what he calls "multiple heaps".

Keep in mind, I'm also shooting from the hip...YMMV.

It looks like it's slightly more subtle than this, but close. Local 
memory in C/C++ goes on a stack, while memory allocated with new (C++) 
or malloc (C) comes from a memory manager (heap space). There are cases 
where people write their own memory managers in order to make more 
efficient allocations for their particular data needs, and this sounds 
similar...but not necessarily voluntary; looks like instead of having a 
different memory manager when two versions of a dll are loaded, they can 
have both heap space allocators at the same time...which implies that 
some address like 0x12345678 allocated with one manager is not the same 
as 0x12345678 allocated with the other manager...and that sometimes 
there are easily made mistakes with one manager using the address named 
from another heap manager (e.g., delete or free called from one manager 
on the space of another). The disturbing thing seems to be that if you 
have multiple library versions installed by various apps on windows, 
that this might happen to you without knowing it, and without coding for 
it. The "up" side to it is that you could intentionally use multiple 
memory managers that are best tuned to data sizes at the same time. In 
linux you wouldn't want to have two at the same time, but you could 
write your own heap manager that is intelligent enough to use two heap 
spaces and allocation patterns (which I think is better...a slight 
overhead increase over separate heaps, but resulting in no possibility 
of allocating/deallocating from the wrong heap).

In linux C++ you can easily write your own memory managers for heap, but 
  you won't accidentally use a mix of heap managers just because two 
libraries on the system might provide a different version to the same 
application without the programmer doing it. Remember: YMMV, I'm also 
making some guesses.

D. Stimits, stimits AT comcast DOT net



More information about the LUG mailing list