reentrant(3) DG/UX R4.11MU05 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.
If a non-reentrant function is denoted with an "*", that means there
is a reentrant counterpart to that function that is named functionr.
Non-reentrant functions:
addseverity asctime * crypt ctermid *
ctime * drand48 ecvt encrypt
endutent endutxent erand48 fcvt
fgetgrent * fgetpwent * fmtmsg getc_unlocked
getchar_unlocked getdate getgrent * getgrgid *
getgrnam * getlogin * getopt getpass
getpwent * getpwnam * getpwuid * getutent
getutid getutline getutmp getutmpx
getutxent getutxid getutxline getws
gmtime * grantpt hcreate hdestroy
hsearch initgroups jrand48 l64a
lckpwdf lcong48 localtime * lrand48
memalign monitor mrand48 nftw
nrand48 pclose popen psiginfo
ptsname putc_unlocked putchar_unlocked putpwent
putspent pututline pututxline putws
rand * readdir * seed48 setkey
setutent setutxent srand48 strtok *
system ttyname * ulckpwdf unlockpt
updwtmp updwtmpx utmpname utmpxname
valloc
Reentrant functions:
_tolower _toupper a64l abort
abs acos acosf acosh
alloca ascftime asctime_r asin
asinf asinh atan atan2
atan2f atanf atanh atexit
atof atoi atol bcmp
bcopy berk_signal bsearch bzero
calloc catclose catgets catopen
cbrt ceil ceilf cfgetispeed
cfgetospeed cfsetispeed cfsetospeed cftime
clearerr clock closedir copysign
cos cosf cosh coshf
ctermid_r ctime_r cuserid dg_block_seek
dg_seek difftime div drem
endgrent endpwent endspent erf
erfc exp expf fabs
fabsf fattach fclose fdetach
fdopen feof ferror fflush
ffs fgetc fgetgrent_r fgetpos
fgetpwent_r fgets fgetspent fgetwc
fgetws fileno finite flockfile
floor floorf fmod fmodf
fopen fpclass fpgetmask fpgetround
fpgetsticky fprintf fpsetmask fpsetround
fpsetsticky fputc fputs fputwc
fputws fread free freopen
fscanf fseek fsetpos ftell
ftok ftruncate ftw funlockfile
fwrite gcvt getc getchar
getcwd getenv getgrent_r getgrgid_r
getgrnam_r getlogin_r getpw getpwent_r
getpwnam_r getpwuid_r gets getspent
getspnam getsubopt gettxt getw
getwc getwchar gmtime_r gsignal
hypot index insque isalnum
isalpha isascii isastream isatty
iscntrl isdigit isgraph isinf
islower isnan isnand isnanf
isprint ispunct isspace isupper
isxdigit itoa j0 j1
jn l3tol labs ldiv
lfind localeconv localtime_r lockf
log log10 log10f logf
longjmp lsearch ltol3 malloc
matherr mblen mbrlen mbrtowc
mbsrtowcs mbstowcs mbtowc memccpy
memchr memcmp memcpy memmove
memset mkfifo mktemp mktime
mlock mlockall msync munlock
munlockall nl_langinfo opendir perror
pfmt pow powf printf
psignal putc putchar putenv
puts putw putwc putwchar
qsort raise rand_r readdir_r
realloc realpath remainder remove
remque rewind rewinddir rint
scanf seekdir setbuf setbuffer
setcat setgrent setjmp setlocale
setpwent setpwfile setspent setvbuf
sigaddset sigdelset sigemptyset sigfillset
sigismember siglongjmp signal sigsetjmp
sin sinf sinh sinhf
sleep snprintf sprintf sqrt
sqrtf srand sscanf ssignal
strcat strchr strcmp strcoll
strcpy strcspn strdup strerror
strftime strlen strncat strncmp
strncpy strpbrk strrchr strspn
strstr strtod strtok_r strtol
strtoul strxfrm swab swapcontext
tan tanf tanh tanhf
tcdrain tcflow tcflush tcgetattr
tcgetpgrp tcgetsid tcsendbreak tcsetattr
tcsetpgrp tdelete telldir tempnam
tfind tmpfile tmpnam toascii
tolower toupper tsearch ttyname_r
ttyslot twalk tzset ungetc
unordered usleep vfprintf vprintf
vsprintf wcrtomb wcsrtombs wcstombs
wctomb y0 y1 yn
SEE ALSO
cancellation(3), intro(3).
Licensed material--property of copyright holder(s)