Re: [gtk-list] Re: how can I trust glib when it has so manymemleaks?

["David C. Hoos, Sr." <david c hoos sr ada95 com>]

-----Original Message-----
From: Ionutz Borcoman <borco@borco-ei.eng.hokudai.ac.jp>
To: gtk-list@redhat.com <gtk-list@redhat.com>
Date: Thursday, March 18, 1999 3:30 AM
Subject: [gtk-list] Re: how can I trust glib when it has so manymemleaks?


>"David C. Hoos, Sr." wrote:
>>
>> In addition, the technique of allocating a chunk of memory to be reused by
an
>> allocator/deallocator within a library is quite common, inasmuch as while
>> malloc() and free() must be general-purpose, the special-purpose
>> allocator/deallocator of a library has specialized knowledge about the
needs
>> of the library, and hence, can do a better job at less cost (both time and
>> space).
>
>> Furthermore, even if a program using malloc()/free() does the right thing,
>> memory can become fragmented -- i.e., there can be plenty of free space,
but
>> in chunks too small to satisfy a particular request.  Memory pools used by
a
>> library can guarantee no fragmentation with appropriate
>> allocation/deallocation schemes, precisely because the special-purpose
library
>> designer knows what the maximum allocation request size can be, and the
>> designer of a malloc()/free() in a general-purpose library cannot.
>
>I undertand this. I do not understand how this memory is recycled after
>program dies.

Well .... you could read the Linux source code to see how it's done ;)