@@ -42,98 +50,102 @@ 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.
_r" suffix.
In order to use librrd in multi-threaded programs you must:
-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
+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.
-
rrd_error_clear() before any call to the
-library. Otherwise the call might fail due to some earlier error.
-Always call rrd_error_clear() before any call to the
+library. Otherwise the call might fail due to some earlier error.
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: +situations or when using the following library functions:
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)
-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
getopt or getopt_long in *_r (neither directly nor
-indirectly).
+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.
rrd_parsetime function!
+
+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)