[rrd-developers] Re: Multi-Threaded JNI code

[Peter Stamfest]

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:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi