NAME¶
rrdthreads - Provisions for linking the RRD library to use in multi-threaded
programs
SYNOPSIS¶
Using librrd in multi-threaded programs requires some extra precautions, as the
RRD library in its original form was not thread-safe at all. This document
describes requirements and pitfalls on the way to use the multi-threaded
version of librrd in your own programs. It also gives hints for future RRD
development to keep the library thread-safe.
Currently only some RRD operations are implemented in a thread-safe way. They
all end in the usual ""_r"" suffix.
DESCRIPTION¶
In order to use librrd in multi-threaded programs you must:
- •
- Link with librrd_th instead of librrd (use
"-lrrd_th" when linking)
- •
- Use the ""_r"" functions instead of the
normal API-functions
- •
- Do not use any at-style time specifications. Parsing of
such time specifications is terribly non-thread-safe.
- •
- Never use non *"_r" functions unless it is
explicitly documented that the function is tread-safe.
- •
- Every thread SHOULD call "rrd_get_context()"
before its first call to any "librrd_th" function in order to
set up thread specific data. This is not strictly required, but it is the
only way to test if memory allocation can be done by this function.
Otherwise the program may die with a SIGSEGV in a low-memory
situation.
- •
- Always call "rrd_error_clear()" before any call
to the library. Otherwise the call might fail due to some earlier
error.
NOTES FOR RRD CONTRIBUTORS¶
Some precautions must be followed when developing RRD from now on:
- •
- Only use thread-safe functions in library code. Many often
used libc functions aren't thread-safe. Take care in the following
situations or when using the following library functions:
- •
- Direct calls to "strerror()" must be avoided: use
"rrd_strerror()" instead, it provides a per-thread error
message.
- •
- The "getpw*", "getgr*",
"gethost*" function families (and some more "get*"
functions) are not thread-safe: use the *"_r" variants
- •
- Time functions: "asctime", "ctime",
"gmtime", "localtime": use *"_r"
variants
- •
- "strtok": use "strtok_r"
- •
- "tmpnam": use "tmpnam_r"
- •
- Many others (lookup documentation)
- •
- A header file named rrd_is_thread_safe.h is provided
that works with the GNU C-preprocessor to "poison" some of the
most common non-thread-safe functions using the "#pragma GCC
poison" directive. Just include this header in source files you want
to keep thread-safe.
- •
- Do not introduce global variables!
If you really, really have to use a global variable you may add a new field
to the "rrd_context" structure and modify rrd_error.c,
rrd_thread_safe.c and rrd_non_thread_safe.c
- •
- Do not use "getopt" or "getopt_long" in
*"_r" (neither directly nor indirectly).
"getopt" uses global variables and behaves badly in a
multi-threaded application when called concurrently. Instead provide a *_r
function taking all options as function parameters. You may provide argc
and **argv arguments for variable length argument lists. See
"rrd_update_r" as an example.
- •
- Do not use the "rrd_parsetime" function!
It uses lots of global variables. You may use it in functions not designed
to be thread-safe, like in functions wrapping the "_r" version
of some operation (e.g., "rrd_create", but not in
"rrd_create_r")
CURRENTLY IMPLEMENTED THREAD SAFE FUNCTIONS¶
Currently there exist thread-safe variants of "rrd_update",
"rrd_create", "rrd_dump", "rrd_info",
"rrd_last", and "rrd_fetch".
AUTHOR¶
Peter Stamfest <peter@stamfest.at>