


     RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))          1111....2222....11113333 ((((2222000000006666----00005555----00004444))))          RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))



     NNNNAAAAMMMMEEEE
          rrdthreads - Provisions for linking the RRD library to use
          in multi-threaded programs

     SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
          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.

     DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
          In order to use librrd in multi-threaded programs you must:

          +o   Link with _l_i_b_r_r_d__t_h instead of _l_i_b_r_r_d (use "-lrrd_th"
              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 "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.

          +o   Always call "rrd_error_clear()" before any call to the
              library. Otherwise the call might fail due to some
              earlier error.

          NNNNOOOOTTTTEEEESSSS FFFFOOOORRRR RRRRRRRRDDDD CCCCOOOONNNNTTTTRRRRIIIIBBBBUUUUTTTTOOOORRRRSSSS

          Some precautions must be followed when developing RRD 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



     Page 1                                          (printed 6/13/06)






     RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))          1111....2222....11113333 ((((2222000000006666----00005555----00004444))))          RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))



                  "rrd_strerror()" 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 "strtok_r"

              +o   "tmpnam": use "tmpnam_r"

              +o   Many others (lookup documentation)

          +o   A header file named _r_r_d__i_s__t_h_r_e_a_d__s_a_f_e._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.

          +o   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 _r_r_d__e_r_r_o_r._c, _r_r_d__t_h_r_e_a_d__s_a_f_e._c and
              _r_r_d__n_o_n__t_h_r_e_a_d__s_a_f_e._c

          +o   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.

          +o   Do not use the "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")

          CCCCUUUURRRRRRRREEEENNNNTTTTLLLLYYYY IIIIMMMMPPPPLLLLEEEEMMMMEEEENNNNTTTTEEEEDDDD TTTTHHHHRRRREEEEAAAADDDD SSSSAAAAFFFFEEEE FFFFUUUUNNNNCCCCTTTTIIIIOOOONNNNSSSS

          Currently there exist thread-safe variants of "rrd_update",
          "rrd_create", "rrd_dump", "rrd_info" and "rrd_last".

     AAAAUUUUTTTTHHHHOOOORRRR



     Page 2                                          (printed 6/13/06)






     RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))          1111....2222....11113333 ((((2222000000006666----00005555----00004444))))          RRRRRRRRDDDDTTTTHHHHRRRREEEEAAAADDDDSSSS((((1111))))



          Peter Stamfest <peter@stamfest.at>






















































     Page 3                                          (printed 6/13/06)



