libwww/Library/src/HTMemory.html - view

File: [Public] / libwww / Library / src / HTMemory.html
Revision 2.12: download - view: text, annotated - select for diffs
Thu May 14 02:10:45 1998 UTC (26 years ago) by frystyk
Branches: MAIN
CVS tags: repeat-requests, before_webdav, Release-5-4-0, Release-5-3-1, Release-5-2-8, Release-5-2-6, Release-5-2, Release-5-1m, HEAD, Before-New-Trace-Messages, Amaya_2_4, Amaya-6-3, Amaya-6-1, Amaya-5-2, Amaya-4-3-2, Amaya-4-3-1, Amaya-4-3, Amaya-4-1-2, Amaya-4-1-0, Amaya-4-0-0, Amaya-3-2-1, Amaya-3-2, Amaya

Changing old pub/WWW links

<HTML> <HEAD>  <TITLE>W3C Sample Code Library libwww Dynamic Memory Handlers</TITLE> </HEAD> <BODY> <H1> Dynamic Memory Handlers </H1> <PRE> /* ** (c) COPYRIGHT MIT 1995. ** Please first read the full copyright statement in the file COPYRIGH. */ </PRE> <P> This module defines any memory handler to be used by libwww for allocating and de-allocating dynamic memory. As dynamic memory may be a scarce resource, it is required that an application can handle memory exhaustion gracefully. This module provides an interface that covers the following situations: <P> <UL> <LI> <A HREF="#Allocation">Handling of allocation, reallocation and de-allocation of dynamic memory</A> <LI> <A HREF="#Memory">Recovering from temporary lack of available memory</A> <LI> <A HREF="#Panic">Panic handling in case a new allocation fails</A> </UL> <P> <B>Note</B>: The Library <I>core</I> provides a default set of memory handlers for allocating and de-allocating dynamic memory. In order to maintain a reasonable performance, they are not registered dynamically but assigned using <I>C style macros</I>. Hence, it is not possible to swap memory handler at run time but this was considered to be a reasonable trade-off. <P> This module is implemented by <A HREF="HTMemory.c">HTMemory.c</A>, and it is a part of the <A HREF="http://www.w3.org/Library/">W3C Sample Code Library</A>. <PRE> #ifndef HTMEMORY_H #define HTMEMORY_H #include "<A HREF="HTUtils.html">HTUtils.h</A>" </PRE> <H2> <A NAME="Allocation">Allocation, Reallocation and De-allocation</A> </H2> <P> The Library provides a default set of methods for handling dynamic memory. They are very basic and essentially identical to the C style <CODE>malloc</CODE>, <CODE>calloc</CODE>, <CODE>realloc</CODE>, and <CODE>free</CODE>: <PRE>extern void* HTMemory_malloc(size_t size); extern void* HTMemory_calloc(size_t count, size_t size); extern void* HTMemory_realloc(void * ptr, size_t size); extern void HTMemory_free(void* ptr); </PRE> <H3> Memory Macros </H3> <P> The methods above are not referred directly in the Library. Instead we use a set of C style macros. If you don't wany any memory management beyond normal malloc and alloc then you can just use that instead of the HTMemory_* function. You can of course also provide your own methods as well. <PRE> #define HT_MALLOC(size) HTMemory_malloc((size)) #define HT_CALLOC(count, size) HTMemory_calloc((count), (size)) #define HT_REALLOC(ptr, size) HTMemory_realloc((ptr), (size)) #define HT_FREE(pointer) {HTMemory_free((pointer));((pointer))=NULL;} </PRE> <H2> <A NAME="Memory">Memory Freer Functions</A> </H2> <P> The dynamic memory freer functions are typically functions that are capable of freeing large chunks of memory. In case a new allocation fails, the allocation method looks for any registered freer functions to call. There can be multiple freer functions and after each call, the allocation method tries again to allocate the desired amount of dynamic memory. The freer functions are called in <EM>reverse</EM> order meaning that the <EM>last</EM> one registered gets called <EM>first</EM>. That way, it is easy to add temporary freer functions which then are guaranteed to be called first if a methods fails. <H3> Add a Freer Function </H3> <P> You can add a freer function by using the following method. The Library may itself register a set of free functions during initialization. If the application does not register any freer functions then the Library looks how it can free internal memory. The freer function is passed the total number of <I>bytes</I> requested by the allocation. <PRE>typedef void HTMemoryCallback(size_t size); extern BOOL HTMemoryCall_add (HTMemoryCallback * cbf); </PRE> <H3> Delete a Freer Function </H3> <P> Freer functions can be deleted at any time in which case they are not called anymore. <PRE> extern BOOL HTMemoryCall_delete (HTMemoryCallback * cbf); extern BOOL HTMemoryCall_deleteAll (void); </PRE> <H2> <A NAME="Panic">Panic Handling</A> </H2> <P> If the freer functions are not capable of de-allocation enough memory then the application must have an organized way of closing down. This is done using the panic handler. In the libwww, each allocation is tested and <CODE>HT_OUTOFMEM</CODE> is called if a <CODE>NULL</CODE> was returned. <CODE>HT_OUTOFMEM</CODE> is a macro which by default calls <CODE>HTMemory_outofmem()</CODE> but of course can point to any method. The default handler calls an exit function defined by the application in a call to <CODE>HTMemory_setExit()</CODE>. If the application has <I>not</I> defined an exit function, <CODE>HTMemory_outofmem()</CODE> prints an error message and calls <CODE>exit(1)</CODE>. <PRE> typedef void HTMemory_exitCallback(char *name, char *file, unsigned long line); extern void HTMemory_setExit(HTMemory_exitCallback * pExit); extern HTMemory_exitCallback * HTMemory_exit(void); </PRE> <H3> Call the Exit Handler </H3> <P> If an allocation fails then this function is called. If the application has registered its own panic handler then this is called directly from this function. Otherwise, the default behavior is to write a small message to stderr and then exit. <PRE> #define outofmem(file, name) HT_OUTOFMEM(name) #define HT_OUTOFMEM(name) HTMemory_outofmem((name), __FILE__, __LINE__) extern void HTMemory_outofmem(char * name, char * file, unsigned long line); </PRE> <PRE> #endif /* HTMEMORY_H */ </PRE> <P> <HR> <ADDRESS> @(#) $Id: HTMemory.html,v 2.12 1998/05/14 02:10:45 frystyk Exp $ </ADDRESS> </BODY></HTML>