| .cvsignore |
|
9 |
| gencfg.c |
/
/* Generate cpucfg.h |
6165 |
| Makefile.in |
|
638 |
| md |
|
|
| nspr.h |
nspr_h___ |
1016 |
| obsolete |
|
|
| pratom.h |
GLOBAL FUNCTIONS:
* DESCRIPTION:
* PR Atomic operations
|
5909 |
| prbit.h |
Replace compare/jump/add/shift sequence with compiler built-in/intrinsic
* functions.
|
5274 |
| prclist.h |
Circular linked list
|
2480 |
| prcmon.h |
Interface to cached monitors. Cached monitors use an address to find a
* given PR monitor. In this way a monitor can be associated with another
* object without preallocating a monitor for all objects.
*
* A hash table is used to quickly map addresses to individual monitors
* and the system automatically grows the hash table as needed.
*
* Cache monitors are about 5 times slower to use than uncached monitors.
|
2145 |
| prcountr.h |
----------------------------------------------------------------------------
* prcountr.h -- NSPR Instrumentation counters
*
* The NSPR Counter Feature provides a means to "count
* something." Counters can be dynamically defined, incremented,
* decremented, set, and deleted under application program
* control.
*
* The Counter Feature is intended to be used as instrumentation,
* not as operational data. If you need a counter for operational
* data, use native integral types.
*
* Counters are 32bit unsigned intergers. On overflow, a counter
* will wrap. No exception is recognized or reported.
*
* A counter can be dynamically created using a two level naming
* convention. A "handle" is returned when the counter is
* created. The counter can subsequently be addressed by its
* handle. An API is provided to get an existing counter's handle
* given the names with which it was originally created.
* Similarly, a counter's name can be retrieved given its handle.
*
* The counter naming convention is a two-level hierarchy. The
* QName is the higher level of the hierarchy; RName is the
* lower level. RNames can be thought of as existing within a
* QName. The same RName can exist within multiple QNames. QNames
* are unique. The NSPR Counter is not a near-zero overhead
* feature. Application designers should be aware of
* serialization issues when using the Counter API. Creating a
* counter locks a large asset, potentially causing a stall. This
* suggest that applications should create counters at component
* initialization, for example, and not create and destroy them
* willy-nilly. ... You have been warned.
*
* Incrementing and Adding to counters uses atomic operations.
* The performance of these operations will vary from platform
* to platform. On platforms where atomic operations are not
* supported the overhead may be substantial.
*
* When traversing the counter database with FindNext functions,
* the instantaneous values of any given counter is that at the
* moment of extraction. The state of the entire counter database
* may not be viewed as atomic.
*
* The counter interface may be disabled (No-Op'd) at compile
* time. When DEBUG is defined at compile time, the Counter
* Feature is compiled into NSPR and applications invoking it.
* When DEBUG is not defined, the counter macros compile to
* nothing. To force the Counter Feature to be compiled into an
* optimized build, define FORCE_NSPR_COUNTERS at compile time
* for both NSPR and the application intending to use it.
*
* Application designers should use the macro form of the Counter
* Feature methods to minimize performance impact in optimized
* builds. The macros normally compile to nothing on optimized
* builds.
*
* Application designers should be aware of the effects of
* debug and optimized build differences when using result of the
* Counter Feature macros in expressions.
*
* The Counter Feature is thread-safe and SMP safe.
*
* /lth. 09-Jun-1998.
|
14757 |
| prcvar.h |
Create a new condition variable.
*
* "lock" is the lock used to protect the condition variable.
*
* Condition variables are synchronization objects that threads can use
* to wait for some condition to occur.
*
* This may fail if memory is tight or if some operating system resource
* is low. In such cases, a NULL will be returned.
|
3593 |
| prdtoa.h |
PR_strtod() returns as a double-precision floating-point number
* the value represented by the character string pointed to by
* s00. The string is scanned up to the first unrecognized
* character.
*a
* If the value of se is not (char **)NULL, a pointer to
* the character terminating the scan is returned in the location pointed
* to by se. If no number can be formed, se is set to s00, and
* zero is returned.
|
1593 |
| prenv.h |
/
/****************************************************************************** |
6209 |
| prerr.h |
prerr.h
This file is automatically generated; please do not edit it.
|
8308 |
| prerror.h |
Set error will preserve an error condition within a thread context.
* The values stored are the NSPR (platform independent) translation of
* the error. Also, if available, the platform specific oserror is stored.
* If there is no appropriate OS error number, a zero my be supplied.
|
11505 |
| prinet.h |
File: prinet.h
Description:
Header file used to find the system header files for socket support[1].
This file serves the following purposes:
- A cross-platform, "get-everything" socket header file. On
Unix, socket support is scattered in several header files,
while Windows has a "get-everything" socket header file[2].
- NSPR needs the following macro definitions and function
prototype declarations from these header files:
AF_INET
INADDR_ANY, INADDR_LOOPBACK, INADDR_BROADCAST
ntohl(), ntohs(), htonl(), ntons().
NSPR does not define its own versions of these macros and
functions. It simply uses the native versions, which have
the same names on all supported platforms.
This file is intended to be included by NSPR public header
files, such as prio.h. One should not include this file directly.
Notes:
1. This file should have been an internal header. Please do not
depend on it to pull in the system header files you need.
2. WARNING: This file is no longer cross-platform as it is a no-op
for WIN32! See the comment in the WIN32 section for details.
|
2851 |
| prinit.h |
/
/**************************IDENTITY AND VERSIONING********************** |
6596 |
| prinrval.h |
File: prinrval.h
* Description: API to interval timing functions of NSPR.
*
*
* NSPR provides interval times that are independent of network time
* of day values. Interval times are (in theory) accurate regardless
* of host processing requirements and also very cheap to acquire. It
* is expected that getting an interval time while in a synchronized
* function (holding one's lock).
|
5339 |
| prio.h |
File: prio.h
Description: PR i/o related stuff, such as file system access, file
i/o, socket i/o, etc.
|
77285 |
| pripcsem.h |
File: pripcsem.h
Description: named semaphores for interprocess
synchronization
Unrelated processes obtain access to a shared semaphore
by specifying its name.
Our goal is to support named semaphores on at least
Unix and Win32 platforms. The implementation will use
one of the three native semaphore APIs: POSIX, System V,
and Win32.
Because POSIX named semaphores have kernel persistence,
we are forced to have a delete function in this API.
|
2640 |
| private |
|
|
| prlink.h |
API to static and dynamic linking.
|
8354 |
| prlock.h |
File: prlock.h
* Description: API to basic locking functions of NSPR.
*
*
* NSPR provides basic locking mechanisms for thread synchronization. Locks
* are lightweight resource contention controls that prevent multiple threads
* from accessing something (code/data) simultaneously.
|
3816 |
| prlog.h |
prlog.h -- Declare interfaces to NSPR's Logging service
*
* NSPR provides a logging service that is used by NSPR itself and is
* available to client programs.
*
* To use the service from a client program, you should create a
* PRLogModuleInfo structure by calling PR_NewLogModule(). After
* creating the LogModule, you can write to the log using the PR_LOG()
* macro.
*
* Initialization of the log service is handled by NSPR initialization.
*
* At execution time, you must enable the log service. To enable the
* log service, set the environment variable: NSPR_LOG_MODULES
* variable.
*
* NSPR_LOG_MODULES variable has the form:
*
* <moduleName>:<value>[, <moduleName>:<value>]*
*
* Where:
* <moduleName> is the name passed to PR_NewLogModule().
* <value> is a numeric constant, e.g. 5. This value is the maximum
* value of a log event, enumerated by PRLogModuleLevel, that you want
* written to the log.
*
* For example: to record all events of greater value than or equal to
* PR_LOG_ERROR for a LogModule names "gizmo", say:
*
* set NSPR_LOG_MODULES=gizmo:2
*
* Note that you must specify the numeric value of PR_LOG_ERROR.
*
* Special LogModule names are provided for controlling NSPR's log
* service at execution time. These controls should be set in the
* NSPR_LOG_MODULES environment variable at execution time to affect
* NSPR's log service for your application.
*
* The special LogModule "all" enables all LogModules. To enable all
* LogModule calls to PR_LOG(), say:
*
* set NSPR_LOG_MODULES=all:5
*
* The special LogModule name "sync" tells the NSPR log service to do
* unbuffered logging.
*
* The special LogModule name "bufsize:<size>" tells NSPR to set the
* log buffer to <size>.
*
* The environment variable NSPR_LOG_FILE specifies the log file to use
* unless the default of "stderr" is acceptable. For MS Windows
* systems, NSPR_LOG_FILE can be set to a special value: "WinDebug"
* (case sensitive). This value causes PR_LOG() output to be written
* using the Windows API OutputDebugString(). OutputDebugString()
* writes to the debugger window; some people find this helpful.
*
*
* To put log messages in your programs, use the PR_LOG macro:
*
* PR_LOG(<module>, <level>, (<printfString>, <args>*));
*
* Where <module> is the address of a PRLogModuleInfo structure, and
* <level> is one of the levels defined by the enumeration:
* PRLogModuleLevel. <args> is a printf() style of argument list. That
* is: (fmtstring, ...).
*
* Example:
*
* main() {
* PRIntn one = 1;
* PRLogModuleInfo * myLm = PR_NewLogModule("gizmo");
* PR_LOG( myLm, PR_LOG_ALWAYS, ("Log this! %d\n", one));
* return;
* }
*
* Note the use of printf() style arguments as the third agrument(s) to
* PR_LOG().
*
* After compiling and linking you application, set the environment:
*
* set NSPR_LOG_MODULES=gizmo:5
* set NSPR_LOG_FILE=logfile.txt
*
* When you execute your application, the string "Log this! 1" will be
* written to the file "logfile.txt".
*
* Note to NSPR engineers: a number of PRLogModuleInfo structures are
* defined and initialized in prinit.c. See this module for ideas on
* what to log where.
*
|
7050 |
| prlong.h |
File: prlong.h
* Description: Portable access to 64 bit numerics
*
* Long-long (64-bit signed integer type) support. Some C compilers
* don't support 64 bit integers yet, so we use these macros to
* support both machines that do and don't.
|
12757 |
| prmem.h |
File: prmem.h
* Description: API to NSPR memory management functions
*
|
4760 |
| prmon.h |
Create a new monitor. Monitors are re-entrant locks with a single built-in
* condition variable.
*
* This may fail if memory is tight or if some operating system resource
* is low.
|
3240 |
| prmwait.h |
/
/******************************************************************************* |
16264 |
| prnetdb.h |
Translate an Internet address to/from a character string
********************************************************************
|
19671 |
| prolock.h |
A locking mechanism, built on the existing PRLock definition,
* is provided that will permit applications to define a Lock
* Hierarchy (or Lock Ordering) schema. An application designed
* using the Ordered Lock functions will terminate with a
* diagnostic message when a lock inversion condition is
* detected.
*
* The lock ordering detection is compile-time enabled only. In
* optimized builds of NSPR, the Ordered Lock functions map
* directly to PRLock functions, providing no lock order
* detection.
*
* The Ordered Lock Facility is compiled in when DEBUG is defined at
* compile-time. Ordered Lock can be forced on in optimized builds by
* defining FORCE_NSPR_ORDERED_LOCK at compile-time. Both the
* application using Ordered Lock and NSPR must be compiled with the
* facility enabled to achieve the desired results.
*
* Application designers should use the macro interfaces to the Ordered
* Lock facility to ensure that it is compiled out in optimized builds.
*
* Application designers are responsible for defining their own
* lock hierarchy.
*
* Ordered Lock is thread-safe and SMP safe.
*
* See Also: prlock.h
*
* /lth. 10-Jun-1998.
*
|
4643 |
| prpdce.h |
File: prpdce.h
Description: This file is the API defined to allow for DCE (aka POSIX)
thread emulation in an NSPR environment. It is not the
intent that this be a fully supported API.
|
2477 |
| prprf.h |
API for PR printf like routines. Supports the following formats
* %d - decimal
* %u - unsigned decimal
* %x - unsigned hex
* %X - unsigned uppercase hex
* %o - unsigned octal
* %hd, %hu, %hx, %hX, %ho - 16-bit versions of above
* %ld, %lu, %lx, %lX, %lo - 32-bit versions of above
* %lld, %llu, %llx, %llX, %llo - 64 bit versions of above
* %s - string
* %c - character
* %p - pointer (deals with machine dependent pointer size)
* %f - float
* %g - float
|
4502 |
| prproces.h |
/
/*****************************PROCESS OPERATIONS************************ |
2306 |
| prrng.h |
prrng.h -- NSPR Random Number Generator
*
*
* lth. 29-Oct-1999.
|
2458 |
| prrwlock.h |
File: prrwlock.h
* Description: API to basic reader-writer lock functions of NSPR.
*
|
2854 |
| prshm.h |
prshm.h -- NSPR Shared Memory
*
* NSPR Named Shared Memory API provides a cross-platform named
* shared-memory interface. NSPR Named Shared Memory is modeled on
* similar constructs in Unix and Windows operating systems. Shared
* memory allows multiple processes to access one or more common shared
* memory regions, using it as an inter-process communication channel.
*
* Notes on Platform Independence:
* NSPR Named Shared Memory is built on the native services offered
* by most platforms. The NSPR Named Shared Memory API tries to
* provide a least common denominator interface so that it works
* across all supported platforms. To ensure that it works everywhere,
* some platform considerations must be accomodated and the protocol
* for using NSPR Shared Memory API must be observed.
*
* Protocol:
* Multiple shared memories can be created using NSPR's Shared Memory
* feature. For each named shared memory, as defined by the name
* given in the PR_OpenSharedMemory() call, a protocol for using the
* shared memory API is required to ensure desired behavior. Failing
* to follow the protocol may yield unpredictable results.
*
* PR_OpenSharedMemory() will create the shared memory segment, if it
* does not already exist, or open a connection that the existing
* shared memory segment if it already exists.
*
* PR_AttachSharedMemory() should be called following
* PR_OpenSharedMemory() to map the memory segment to an address in
* the application's address space.
*
* PR_AttachSharedMemory() may be called to re-map a shared memory
* segment after detaching the same PRSharedMemory object. Be
* sure to detach it when done.
*
* PR_DetachSharedMemory() should be called to un-map the shared
* memory segment from the application's address space.
*
* PR_CloseSharedMemory() should be called when no further use of the
* PRSharedMemory object is required within a process. Following a
* call to PR_CloseSharedMemory() the PRSharedMemory object is
* invalid and cannot be reused.
*
* PR_DeleteSharedMemory() should be called before process
* termination. After calling PR_DeleteSharedMemory() any further use
* of the shared memory associated with the name may cause
* unpredictable results.
*
* Files:
* The name passed to PR_OpenSharedMemory() should be a valid filename
* for a unix platform. PR_OpenSharedMemory() creates file using the
* name passed in. Some platforms may mangle the name before creating
* the file and the shared memory.
*
* The unix implementation may use SysV IPC shared memory, Posix
* shared memory, or memory mapped files; the filename may used to
* define the namespace. On Windows, the name is significant, but
* there is no file associated with name.
*
* No assumptions about the persistence of data in the named file
* should be made. Depending on platform, the shared memory may be
* mapped onto system paging space and be discarded at process
* termination.
*
* All names provided to PR_OpenSharedMemory() should be valid
* filename syntax or name syntax for shared memory for the target
* platform. Referenced directories should have permissions
* appropriate for writing.
*
* Limits:
* Different platforms have limits on both the number and size of
* shared memory resources. The default system limits on some
* platforms may be smaller than your requirements. These limits may
* be adjusted on some platforms either via boot-time options or by
* setting the size of the system paging space to accomodate more
* and/or larger shared memory segment(s).
*
* Security:
* On unix platforms, depending on implementation, contents of the
* backing store for the shared memory can be exposed via the file
* system. Set permissions and or access controls at create and attach
* time to ensure you get the desired security.
*
* On windows platforms, no special security measures are provided.
*
* Example:
* The test case pr/tests/nameshm1.c provides an example of use as
* well as testing the operation of NSPR's Named Shared Memory.
*
* lth. 18-Aug-1999.
|
8468 |
| prshma.h |
prshma.h -- NSPR Anonymous Shared Memory
*
* NSPR provides an anonymous shared memory based on NSPR's PRFileMap
* type. The anonymous file-mapped shared memory provides an inheritable
* shared memory, as in: the child process inherits the shared memory.
* Compare the file-mapped anonymous shared memory to to a named shared
* memory described in prshm.h. The intent is to provide a shared
* memory that is accessable only by parent and child processes. ...
* It's a security thing.
*
* Depending on the underlying platform, the file-mapped shared memory
* may be backed by a file. ... surprise! ... On some platforms, no
* real file backs the shared memory. On platforms where the shared
* memory is backed by a file, the file's name in the filesystem is
* visible to other processes for only the duration of the creation of
* the file, hopefully a very short time. This restricts processess
* that do not inherit the shared memory from opening the file and
* reading or writing its contents. Further, when all processes
* using an anonymous shared memory terminate, the backing file is
* deleted. ... If you are not paranoid, you're not paying attention.
*
* The file-mapped shared memory requires a protocol for the parent
* process and child process to share the memory. NSPR provides two
* protocols. Use one or the other; don't mix and match.
*
* In the first protocol, the job of passing the inheritable shared
* memory is done via helper-functions with PR_CreateProcess(). In the
* second protocol, the parent process is responsible for creating the
* child process; the parent and child are mutually responsible for
* passing a FileMap string. NSPR provides helper functions for
* extracting data from the PRFileMap object. ... See the examples
* below.
*
* Both sides should adhere strictly to the protocol for proper
* operation. The pseudo-code below shows the use of a file-mapped
* shared memory by a parent and child processes. In the examples, the
* server creates the file-mapped shared memory, the client attaches to
* it.
*
* First protocol.
* Server:
*
* fm = PR_OpenAnonFileMap(dirName, size, FilemapProt);
* addr = PR_MemMap(fm);
* attr = PR_NewProcessAttr();
* PR_ProcessAttrSetInheritableFileMap( attr, fm, shmname );
* PR_CreateProcess(Client);
* PR_DestroyProcessAttr(attr);
* ... yadda ...
* PR_MemUnmap( addr );
* PR_CloseFileMap(fm);
*
*
* Client:
* ... started by server via PR_CreateProcess()
* fm = PR_GetInheritedFileMap( shmname );
* addr = PR_MemMap(fm);
* ... yadda ...
* PR_MemUnmap(addr);
* PR_CloseFileMap(fm);
*
*
* Second Protocol:
* Server:
*
* fm = PR_OpenAnonFileMap(dirName, size, FilemapProt);
* fmstring = PR_ExportFileMapAsString( fm );
* addr = PR_MemMap(fm);
* ... application specific technique to pass fmstring to child
* ... yadda ... Server uses his own magic to create child
* PR_MemUnmap( addr );
* PR_CloseFileMap(fm);
*
*
* Client:
* ... started by server via his own magic
* ... application specific technique to find fmstring from parent
* fm = PR_ImportFileMapFromString( fmstring )
* addr = PR_MemMap(fm);
* ... yadda ...
* PR_MemUnmap(addr);
* PR_CloseFileMap(fm);
*
*
* lth. 2-Jul-1999.
*
* Note: The second protocol was requested by NelsonB (7/1999); this is
* to accomodate servers which already create their own child processes
* using platform native methods.
*
|
7138 |
| prsystem.h |
API to NSPR functions returning system info.
|
2698 |
| prthread.h |
API for NSPR threads. On some architectures (Mac OS Classic
* notably) pre-emptibility is not guaranteed. Hard priority scheduling
* is not guaranteed, so programming using priority based synchronization
* is a no-no.
*
* NSPR threads are scheduled based loosely on their client set priority.
* In general, a thread of a higher priority has a statistically better
* chance of running relative to threads of lower priority. However,
* NSPR uses multiple strategies to provide execution vehicles for thread
* abstraction of various host platforms. As it turns out, there is little
* NSPR can do to affect the scheduling attributes of "GLOBAL" threads.
* However, a semblance of GLOBAL threads is used to implement "LOCAL"
* threads. An arbitrary number of such LOCAL threads can be assigned to
* a single GLOBAL thread.
*
* For scheduling, NSPR will attempt to run the highest priority LOCAL
* thread associated with a given GLOBAL thread. It is further assumed
* that the host OS will apply some form of "fair" scheduling on the
* GLOBAL threads.
*
* Threads have a "system flag" which when set indicates the thread
* doesn't count for determining when the process should exit (the
* process exits when the last user thread exits).
*
* Threads also have a "scope flag" which controls whether the threads
* are scheduled in the local scope or scheduled by the OS globally. This
* indicates whether a thread is permanently bound to a native OS thread.
* An unbound thread competes for scheduling resources in the same process.
*
* Another flag is "state flag" which control whether the thread is joinable.
* It allows other threads to wait for the created thread to reach completion.
*
* Threads can have "per-thread-data" attached to them. Each thread has a
* per-thread error number and error string which are updated when NSPR
* operations fail.
|
10085 |
| prtime.h |
----------------------------------------------------------------------
prtime.h --
NSPR date and time functions
-----------------------------------------------------------------------
|
10235 |
| prtpool.h |
NOTE:
THIS API IS A PRELIMINARY VERSION IN NSPR 4.0 AND IS SUBJECT TO
CHANGE
|
2376 |
| prtrace.h |
prtrace.h -- NSPR's Trace Facility.
*
* The Trace Facility provides a means to trace application
* program events within a process. When implementing an
* application program an engineer may insert a "Trace" function
* call, passing arguments to be traced. The "Trace" function
* combines the user trace data with identifying data and
* writes this data in time ordered sequence into a circular
* in-memory buffer; when the buffer fills, it wraps.
*
* Functions are provided to set and/or re-configure the size of
* the trace buffer, control what events are recorded in the
* buffer, enable and disable tracing based on specific user
* supplied data and other control functions. Methods are provided
* to record the trace entries in the in-memory trace buffer to
* a file.
*
* Tracing may cause a performance degredation to the application
* depending on the number and placement of calls to the tracing
* facility. When tracing is compiled in and all tracing is
* disabled via the runtime controls, the overhead should be
* minimal. ... Famous last words, eh?
*
* When DEBUG is defined at compile time, the Trace Facility is
* compiled as part of NSPR and any application using NSPR's
* header files will have tracing compiled in. When DEBUG is not
* defined, the Trace Facility is not compiled into NSPR nor
* exported in its header files. If the Trace Facility is
* desired in a non-debug build, then FORCE_NSPR_TRACE may be
* defined at compile time for both the optimized build of NSPR
* and the application. NSPR and any application using NSPR's
* Trace Facility must be compiled with the same level of trace
* conditioning or unresolved references may be realized at link
* time.
*
* For any of the Trace Facility methods that requires a trace
* handle as an input argument, the caller must ensure that the
* trace handle argument is valid. An invalid trace handle
* argument may cause unpredictable results.
*
* Trace Facility methods are thread-safe and SMP safe.
*
* Users of the Trace Facility should use the defined macros to
* invoke trace methods, not the function calls directly. e.g.
* PR_TRACE( h1,0,1,2, ...); not PR_Trace(h1,0,1,2, ...);
*
* Application designers should be aware of the effects of
* debug and optimized build differences when using result of the
* Trace Facility macros in expressions.
*
* See Also: prcountr.h
*
* /lth. 08-Jun-1998.
|
20675 |
| prtypes.h |
File: prtypes.h
* Description: Definitions of NSPR's basic types
*
* Prototypes and macros used to make up for deficiencies that we have found
* in ANSI environments.
*
* Since we do not wrap <stdlib.h> and all the other standard headers, authors
* of portable code will not know in general that they need these definitions.
* Instead of requiring these authors to find the dependent uses in their code
* and take the following steps only in those C files, we take steps once here
* for all C files.
|
19756 |
| prvrsion.h |
author: jstewart |
3547 |
| prwin.h |
Condition use of this header on platform.
|
5949 |