[R] Multi-threaded external routines with R?

[Harry Mangalam]

"Jens Oehlschlägel-Akiyoshi" <jens.oehlschlaegel-akiyoshi at mdfactory.de>
asked for a summary of what I got in response what I previously wrote:

> While R is not multi-threaded, it supports dynamic loading of external
> routines writ in C or Fortran.  It seems that it should be possible to link
> in multi-threaded code as easily as serial code, as long as the external
> routine syncs correctly and returns valid R objects.
> 
> Is this true or ar there R internals that would prevent this?

from a short corresp with Duncan Temple Lang
<duncan at rice.research.bell-labs.com>,
I learned that it should be possible, but perhaps somewhat tricky as it
depends considerably on what the behavior of the linker/loader and perhaps
makefile that you use to assemble this frankenstein.

Theoretically it shouldn't be too difficult (beyond the usual difficulties
of building and debugging such a routine).  R calls an external function
with .C() or .Call(), waits for the completion of this routine, and it
returns an R object in the correct format.

But...

Duncan wrote:

> > However, one of the real problems you may have is that the R
> > executable itself will probably not have been compiled and linked with
> > threads in mind (i.e -D_REENTRANT, linking with -lpthread or
> > -lthread).  Thus on some systems, the dynamically loaded code may end
> > up calling the non-reentrant versions of the system routines and other
> > libraries linked in to the R executable. If one is lucky, this will be
> > obvious; Unlucky means getting unreproducible incorrect results.

and further, he wrote:

"the problem is that suppose R links in a call to malloc(), which
it does. Then when your code is loaded it will potentiall resolve its
malloc() from the one in the executable into which it is being
loaded. I think this is linker and loader dependent.  But if that does
happen, the malloc you get will not be thread-safe. Hence two of your
threads may call it and get wrong results.  This can happen for any of
the routines that the R executable provides to the dynamically loaded
code. This may not be a problem on your system depending on the linker
and loader but it probably requires a little checking."

so if R has been compiled with a thread-UNSAFE malloc or other memory
allocator, and your linker resolves calls from your THREADED program with
this fn(), you will often/always end up with gibberish.  The safer way, I
guess it to force static linking in your threaded routine at compile time
(gcc -static), so that there are no unresolved symbols at link time.


> If it is true, can anyone point me to examples of this kind of usage?

nothing on this so far, and I haven't attempted this, so I can't be of more
concrete help on this yet.

Hope this was of some help..
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 -- mangalam at home.com
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._