Hello Robert, [Also including the list, as this is probably useful for others as well]
On Mon, 24 Jul 2006, Robert Halstead wrote: > Hi Peter, > > Just checking back with you for my last email. Any input would be nice Sorry, I missed that mail. Thanks for writing again. > > I'm having some problems with the error function in rrd.h. I looked > > through rrd.h and noticed that all the multi threaded error functions are > > commented out. Is this right? Am I not including a .h file that i'm > > supposed to? The trick is the interaction between the code in rrd_error.c, rrd_not_thread_safe.c and rrd_thread_safe.c: In rrd_error.c we have: #define CTX (rrd_get_context()) and for all the functions in question we have code like this: char * rrd_get_error(void){ return CTX->rrd_error; } The distinction between thread safe vs. non-safe code is made by using either rrd_thread_safe.c or rrd_not_thread_safe.c. rrd_thread_safe.c uses thread local variables to access per-thread information while rrd_not_thread_safe.c just uses global variables. The idea is as follows: Any thread uses thread-safe RRD functions in whatever way it wishes. After that, it checks the error by calling rrd_get_error, which will _implicitly_ return the correct (per-thread) error information. So there do not have to be any _r functions for this. The reason why they exist in a commented-out version is that before I implemented this using thread-local variables I tried to use the rrd_context based solution (An rrd_context COULD in the future be used to distinguis between different RRD operations). However, this turned out to be a major PITA, due to the sheer amount of calls to the error-handling functions. The initial attempt would have required to pass the context to almost every function in the RRD library - which would be ugly and boring to implement. So I got rid of the rrd_context again and only kept it internally. There is one problem, though: It is not possible to check the error occuring in one thread from another thread. However, this would be rather simple to implement be resurrecting the _r error functions and also declaring the rrd_get_context function to be part of the official API. But personally I had/have no use for this (yet?). > > > > #include "com_bresnan_cacti_archiver_RRD.h" > > #include <rrd.h> > > > > // Needed for rrdtool under multi-threading > > #include "rrd_is_thread_safe.h" Note: This is not really _needed_. It is just a helper to avoid some common problems with non-thread-safe library functions by poisoning them by using a GCC pragma. It probably does not do anything on newer GCCs, but I dunno really. Someone out there wanting to investigate this? > > that's what i'm including in the c file. > > I would like to get the errors, but get a unresolved link error at runtime > > on rrd_test_error_r(). > > Use rrd_test_error() instead. It should work (and be thread safe). If it does not (or isn't), it is an error and requires fixing. It would be great if you could test this by stress testing your code, just to make sure that the thread safe stuff works together with how java thinks about threads. Also note that thread-safety stuff can be dependent on the system, this is why there even is a rrd_thread_safe_nt.c file (which AFAIR I have never actually looked at until just now, see the following paragraph). The error handling functions _might_ contain a memory leak with the thread-local variables, if the system-dependent handling is not implemented correctly wrt to exiting threads (at which time the thread-local stuff must be free'd). After a quick look at the NT version this _might_ be the case there, but I don't know threads on Windows well enough to really say for sure. The posix thread version should have no leaks in that area. peter -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi