reentrant(3) SDK R4.11 reentrant(3)
NAME
reentrant - DG/UX reentrant libraries for threads.
DESCRIPTION
The threads programming model requires that applications call only
those library functions which are known to be reentrant. This man
page discusses issues specific to using reentrant libraries. It has
the following sections:
· Definitions
· Stack Consumption
· Global State
· Thread Cancellation
· Functions Using Signals
· Existing Functions
This man page provides a snapshot of what functions within the
(3*) set of man pages are reentrant and non-reentrant.
Definitions
Here are some are some definitions of terms used throughout the (3*)
set of man pages.
reentrant function A function whose effect, when called by two or
more threads, is guaranteed to be as if the
threads each executed the function one after
another in an undefined order, even if the
actual execution is interleaved.
threaded application An application which is linked with the thread
library (-lthread).
Stack Consumption
You may run into situations where your threaded application will core
dump due to stack space limitations. If this occurs, increase your
stack size from the default. To find the current stack size, use the
thread creation attribute pthreadattrgetstacksize(). To set the
stack use the thread creation attribute pthreadattrsetstacksize().
Global State
Some library functions read or write global data. Since threaded
applications are no longer serial in nature, you need to be careful
when accessing these global data, or when calling library routines
which access them. It is now possible for library functions and
threaded applications to change global data out from under each
other. Some examples are the global variables ctype, daylight,
optind, etc.
The man pages for the POSIX library functions detail when global data
is used. See the specific man page for more details.
Thread Cancellation
The POSIX standard for threads programming,P1003.4a, is in draft
form. Thread cancellation is one area that is still undergoing
refinement. For example, P1003.4a draft 6 requires only that an
implementation document which functions can recognize cancellation
requests. Draft 8 requires that only certain functions be able to
recognize cancellation requests. It is possible for application
behavior to change or be broken completely whenever a function's
cancellation behavior is changed. We therefore recommend that if
cancellation must be used, the application should make no assumption
about the cancellability of any functions. A coding paradigm that
insulates the application from changes in this area includes:
· If calling any DG/UX functions from the thread, always first
push a cleanup handler if there is state that might need
cleanup if any of the functions being called is a cancellation
point. The pthread_setintr() call can be used to explicitly
turn cancellability off and on within a thread.
· Wherever a thread is required to recognize cancellation, use a
call to pthread_testintr(). Do not rely on any particular
function to contain a cancellation point.
These steps should help insure that as cancellation points are added
or removed in future revisions of DG/UX, your application will
continue to behave in the expected manner.
Functions Using Signals
Some functions traditionally modify signal state. The system
function is an example. It changes and then replaces the handlers
for SIGINT, SIGQUIT and SIGCLD. Since signal handlers are global to
the process, all threads see these changes. Therefore, system
technically is not reentrant. Processes which depend on signals and
use threads are discouraged (see threads.5).
Existing Functions
Many previously existing DG/UX functions were not reentrant to start
with. Close analysis of libc, libdgc and libm has shown which
functions require changes. Changes have been completed in the
following areas.
Functions specified in POSIX 1003.1 are reentrant with the exceptions
identified in POSIX 1003.4a Draft 6 (_r functions).
Functions used in the implementation of POSIX functions are
reentrant. Sometimes these functions are not in the POSIX standard.
Licensed material--property of copyright holder(s)