[rrd-developers] Re: Multi-Threaded JNI code
peter at stamfest.at
Mon Jul 24 20:34:48 MEST 2006
[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:
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
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.
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
More information about the rrd-developers