Changeset 345
- Timestamp:
- Mar 31, 2004, 5:45:02 PM (22 years ago)
- File:
-
- 1 edited
-
trunk/doc/pslib/psLibSDRS.tex (modified) (11 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/pslib/psLibSDRS.tex
r338 r345 1 %%% $Id: psLibSDRS.tex,v 1.1 7 2004-04-01 02:40:28price Exp $1 %%% $Id: psLibSDRS.tex,v 1.18 2004-04-01 03:45:02 price Exp $ 2 2 \documentclass[panstarrs]{panstarrs} 3 3 … … 71 71 astronomical data handling tasks. 72 72 73 PSLib consists of a collection of library function calls -- the74 Application Programming Interfaces (APIs) -- and the associated data73 PSLib consists of a collection of library function calls --- the 74 Application Programming Interfaces (APIs) --- and the associated data 75 75 structures. The capabilities provided by PSLib are grouped into the 76 76 following areas: … … 145 145 We need to provide a mechanism for tracking and fixing memory leaks. 146 146 While it is possible to do this by linking with external libraries 147 (e.g.\ Electric Fence, \href{gnu.org}), it is convenient to do so147 (e.g.\ \href{gnu.org}{Electric Fence}), it is convenient to do so 148 148 within the \PS{} framework. 149 149 … … 170 170 171 171 Within the PSLib memory management system, every allocated memory 172 block which is provided to the user is bounded by two addition s memory173 segments. The segment preceeding the user-memory contains data172 block which is provided to the user is bounded by two additional 173 memory segments. The segment preceeding the user-memory contains data 174 174 describing the allocated block, using the \code{psMemBlock} structure. 175 175 The final element of this structure is a \code{void} pointer called … … 182 182 requests $N$ bytes of memory, the memory management system in fact 183 183 allocates \code{N + sizeof(psMemBlock) + sizeof(void)} bytes, starting 184 at a par icular address, \code{ADDR}. It then fills in the first184 at a particular address, \code{ADDR}. It then fills in the first 185 185 \code{sizeof(psMemBlock)} bytes with the data of the \code{psMemBlock} 186 186 structure, and the last \code{sizeof(void)} bytes with the … … 189 189 management system reallocates a block of memory, it must also allocate 190 190 the additional space and fill in the boundary values. If the memory 191 management system is give a specific pointer for some operation, it is191 management system is given a specific pointer for some operation, it is 192 192 able to find the corresponding \code{psMemBlock} by simply subtracting 193 193 \code{sizeof(psMemBlock)} from the pointer address. … … 199 199 one where the coder mis-counts the range and either fills the data 200 200 just before the start of the valid memory or just after the end of the 201 valid memory. These actions will alter the boundary-post values and202 can be detected by the memory management system. In the second case, 203 hexidecimal dumps of large blocks of memory are easier to examine if 204 the value of \code{PS_MEM_MAGIC} is chosen to catch the eye. A 205 traditional value for \code{PS_MEM_MAGIC} is \code{0xdeadbeef} which 206 is also easily recognized in a dump of the memory table. 201 valid memory. These actions will (hopefully) alter the boundary-post 202 values, which can be detected by the memory management system. In the 203 second case, hexadecimal dumps of large blocks of memory are easier to 204 examine if the value of \code{PS_MEM_MAGIC} is chosen to catch the 205 eye. A traditional value for \code{PS_MEM_MAGIC} is \code{0xdeadbeef} 206 which is also easily recognized in a dump of the memory table. 207 207 208 208 The PSLib memory management system must maintain a private table of … … 247 247 deleted. Valid states are \code{PS_MEM_FREE} and \code{PS_MEM_ALLOC}. 248 248 249 \subsubsection{APIs for Allocati onand Freeing}249 \subsubsection{APIs for Allocating and Freeing} 250 250 251 251 PSLib provides the following APIs to create and destroy memory blocks: … … 281 281 \code{malloc}, \code{calloc}, \code{realloc}, or \code{free} will not 282 282 compile. This may be achieved by defining preprocessor macros which 283 mask these functions with invalid statements (\eg{} \code{#define 284 malloc(S) for}). In exceptional cases, such as the memory management 285 system itself, programmers may choose to override this prohibition by 286 defining the symbol \code{PS_ALLOW_MALLOC}. Application code will 287 call \code{p_psAlloc,p_psRealloc,p_psFree} via the macros defined 288 above. 283 mask these functions with invalid statements (\eg{} \code{#define malloc(S) for}). 284 In exceptional cases, such as the memory management system itself, 285 programmers may choose to override this prohibition by defining the 286 symbol \code{PS_ALLOW_MALLOC}. Application code will call 287 \code{p_psAlloc,p_psRealloc,p_psFree} via the macros defined above. 289 288 290 289 The functions \code{psAlloc} and \code{psRealloc} shall never return a 291 290 \code{NULL} pointer. If they are unable to provide the requested 292 291 memory they should attempt to obtain the desired memory by calling the 293 routine registered by \code{psMemExhaustedSetCB} (see subsubsection 294 \ref{secMemAdvanced}), and if still unsuccessful, call \code{psAbort()}. 292 routine registered by \code{psMemExhaustedSetCB} (see 293 \S\ref{secMemAdvanced}), and if still unsuccessful, call 294 \code{psAbort()}. 295 295 296 296 Note that we have not specified an equivalent of the \code{calloc} … … 340 340 % 341 341 \begin{verbatim} 342 typedef void *(*psMemExhaustedCB)(size_t size);342 typedef void (*psMemExhaustedCB)(size_t size); 343 343 psMemExhaustedCB psMemExhaustedCBSet(psMemExhaustedCB func); 344 344 \end{verbatim} … … 366 366 are expected. The callback is for informational purposes only. Where 367 367 practical and efficient, the memory manager shall call the routine 368 registered using the \code{psMemProblemCBSet} whenever a corrupted369 block of memory is discovered. For example, doubly-freed blocks can 370 be detected by checking \code{psMemBlock.refcntr}.368 registered using \code{psMemProblemCBSet} whenever a corrupted block 369 of memory is discovered. For example, doubly-freed blocks can be 370 detected by checking \code{psMemBlock.refCounter}. 371 371 372 372 \subsubsubsection{\tt psMemAllocateCB \& psMemFreeCB}
Note:
See TracChangeset
for help on using the changeset viewer.
