rrdtool RDTHREADS(1)
NAME
rrdthreads - Provisions for linking the RD library to use
in multi-threaded programs
SYNOPSIS
Using librrd in multi-threaded programs requires some extra
precautions, as the RD 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
RD development to keep the library thread-safe.
Currently only some RD 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:
]o Link with librrdth instead of librrd (use "-lrrdth"
when linking)
]o Use the ""r"" functions instead of the normal API-
functions
]o Do not use any at-style time specifications. Parsing of
such time specifications is terribly non-thread-safe.
]o Never use non *"r" functions unless it is explicitly
documented that the function is tread-safe.
]o Every thread SHOULD call "rrdgetcontext()" before its
first call to any "librrdth" 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.
]o Always call "rrderrorclear()" before any call to the
library. Otherwise the call might fail due to some
earlier error.
NOTES FOR RD CONTRIBUTORS
Some precautions must be followed when developing RD from
now on:
]o 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:
]o Direct calls to "strerror()" must be avoided: use
1.3.5 Last change: 2008-06-08 1
rrdtool RDTHREADS(1)
"rrdstrerror()" instead, it provides a per-thread
error message.
]o The "getpw*", "getgr*", "gethost*" function families
(and some more "get*" functions) are not
thread-safe: use the *"r" variants
]o Time functions: "asctime", "ctime", "gmtime",
"localtime": use *"r" variants
]o "strtok": use "strtokr"
]o "tmpnam": use "tmpnamr"
]o Many others (lookup documentation)
]o A header file named rrdisthreadsafe.h is provided
that works with the GNU C-preprocessor to "poison" some
of the most common non-thread-safe functions using the
"#pragma GC poison" directive. Just include this header
in source files you want to keep thread-safe.
]o Do not introduce global variables!
If you really, really have to use a global variable you
may add a new field to the "rrdcontext" structure and
modify rrderror.c, rrdthreadsafe.c and
rrdnonthreadsafe.c
]o Do not use "getopt" or "getoptlong" 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
"rrdupdater" as an example.
]o Do not use the "rrdparsetime" 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., "rrdcreate", but not in "rrdcreater")
CURENTLY IMPLEMENTED THREAD SAFE FUNCTIONS
Currently there exist thread-safe variants of "rrdupdate",
"rrdcreate", "rrddump", "rrdinfo", "rrdlast", and
"rrdfetch".
1.3.5 Last change: 2008-06-08 2
rrdtool RDTHREADS(1)
AUTHOR
Peter Stamfest
1.3.5 Last change: 2008-06-08 3
|