IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changeset 345


Ignore:
Timestamp:
Mar 31, 2004, 5:45:02 PM (22 years ago)
Author:
Paul Price
Message:

Fixing typos.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/doc/pslib/psLibSDRS.tex

    r338 r345  
    1 %%% $Id: psLibSDRS.tex,v 1.17 2004-04-01 02:40:28 price Exp $
     1%%% $Id: psLibSDRS.tex,v 1.18 2004-04-01 03:45:02 price Exp $
    22\documentclass[panstarrs]{panstarrs}
    33
     
    7171astronomical data handling tasks.
    7272
    73 PSLib consists of a collection of library function calls -- the
    74 Application Programming Interfaces (APIs) -- and the associated data
     73PSLib consists of a collection of library function calls --- the
     74Application Programming Interfaces (APIs) --- and the associated data
    7575structures.  The capabilities provided by PSLib are grouped into the
    7676following areas:
     
    145145  We need to provide a mechanism for tracking and fixing memory leaks.
    146146  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 so
     147  (e.g.\ \href{gnu.org}{Electric Fence}), it is convenient to do so
    148148  within the \PS{} framework.
    149149
     
    170170
    171171Within the PSLib memory management system, every allocated memory
    172 block which is provided to the user is bounded by two additions memory
    173 segments.  The segment preceeding the user-memory contains data
     172block which is provided to the user is bounded by two additional
     173memory segments.  The segment preceeding the user-memory contains data
    174174describing the allocated block, using the \code{psMemBlock} structure.
    175175The final element of this structure is a \code{void} pointer called
     
    182182requests $N$ bytes of memory, the memory management system in fact
    183183allocates \code{N + sizeof(psMemBlock) + sizeof(void)} bytes, starting
    184 at a paricular address, \code{ADDR}.  It then fills in the first
     184at a particular address, \code{ADDR}.  It then fills in the first
    185185\code{sizeof(psMemBlock)} bytes with the data of the \code{psMemBlock}
    186186structure, and the last \code{sizeof(void)} bytes with the
     
    189189management system reallocates a block of memory, it must also allocate
    190190the additional space and fill in the boundary values.  If the memory
    191 management system is give a specific pointer for some operation, it is
     191management system is given a specific pointer for some operation, it is
    192192able to find the corresponding \code{psMemBlock} by simply subtracting
    193193\code{sizeof(psMemBlock)} from the pointer address.
     
    199199one where the coder mis-counts the range and either fills the data
    200200just 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 and
    202 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. 
     201valid memory.  These actions will (hopefully) alter the boundary-post
     202values, which can be detected by the memory management system.  In the
     203second case, hexadecimal dumps of large blocks of memory are easier to
     204examine if the value of \code{PS_MEM_MAGIC} is chosen to catch the
     205eye.  A traditional value for \code{PS_MEM_MAGIC} is \code{0xdeadbeef}
     206which is also easily recognized in a dump of the memory table.
    207207
    208208The PSLib memory management system must maintain a private table of
     
    247247deleted.  Valid states are \code{PS_MEM_FREE} and \code{PS_MEM_ALLOC}.
    248248
    249 \subsubsection{APIs for Allocation and Freeing}
     249\subsubsection{APIs for Allocating and Freeing}
    250250
    251251PSLib provides the following APIs to create and destroy memory blocks:
     
    281281\code{malloc}, \code{calloc}, \code{realloc}, or \code{free} will not
    282282compile.  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.
     283mask these functions with invalid statements (\eg{} \code{#define malloc(S) for}).
     284In exceptional cases, such as the memory management system itself,
     285programmers may choose to override this prohibition by defining the
     286symbol \code{PS_ALLOW_MALLOC}.  Application code will call
     287\code{p_psAlloc,p_psRealloc,p_psFree} via the macros defined above.
    289288 
    290289The functions \code{psAlloc} and \code{psRealloc} shall never return a
    291290\code{NULL} pointer. If they are unable to provide the requested
    292291memory 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()}.
     292routine registered by \code{psMemExhaustedSetCB} (see
     293\S\ref{secMemAdvanced}), and if still unsuccessful, call
     294\code{psAbort()}.
    295295
    296296Note that we have not specified an equivalent of the \code{calloc}
     
    340340%
    341341\begin{verbatim}
    342 typedef void *(*psMemExhaustedCB)(size_t size);
     342typedef void (*psMemExhaustedCB)(size_t size);
    343343psMemExhaustedCB psMemExhaustedCBSet(psMemExhaustedCB func);
    344344\end{verbatim}
     
    366366are expected.  The callback is for informational purposes only.  Where
    367367practical and efficient, the memory manager shall call the routine
    368 registered using the \code{psMemProblemCBSet} whenever a corrupted
    369 block of memory is discovered.  For example, doubly-freed blocks can
    370 be detected by checking \code{psMemBlock.refcntr}.
     368registered using \code{psMemProblemCBSet} whenever a corrupted block
     369of memory is discovered.  For example, doubly-freed blocks can be
     370detected by checking \code{psMemBlock.refCounter}.
    371371
    372372\subsubsubsection{\tt psMemAllocateCB \& psMemFreeCB}
Note: See TracChangeset for help on using the changeset viewer.