rrdthreads - Provisions for linking the RRD library to use in multi-threaded programs

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 "CW_r" suffix.

In order to use librrd in multi-threaded programs you must:

•

Link with librrd_th instead of librrd (use CW-lrrd_th when linking)

•

Use the "CW_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 *CW_r functions unless it is explicitly documented that the function is tread-safe.

•

Every thread SHOULD call CWrrd_get_context() before its first call to any CWlibrrd_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 CWrrd_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:

•

Direct calls to CWstrerror() must be avoided: use CWrrd_strerror() instead, it provides a per-thread error message.

•

The CWgetpw*, CWgetgr*, CWgethost* function families (and some more CWget* functions) are not thread-safe: use the *CW_r variants

•

Time functions: CWasctime, CWctime, CWgmtime, CWlocaltime: use *CW_r variants

•

CWstrtok: use CWstrtok_r

•

CWtmpnam: use CWtmpnam_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 CW#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 CWrrd_context structure and modify rrd_error.c, rrd_thread_safe.c and rrd_non_thread_safe.c

•

Do not use CWgetopt or CWgetopt_long in *CW_r (neither directly nor indirectly). CWgetopt 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 CWrrd_update_r as an example.

•

Do not use the CWparsetime function! It uses lots of global variables. You may use it in functions not designed to be thread-safe, like in functions wrapping the CW_r version of some operation (e.g., CWrrd_create, but not in CWrrd_create_r)

Currently there exist thread-safe variants of CWrrd_update, CWrrd_create, CWrrd_dump, CWrrd_info and CWrrd_last.

Peter Stamfest <peter@stamfest.at>