Skip to content

Reloading a shared library with dyn.load

5 messages · James Wettenhall, Duncan Temple Lang, Brian Ripley +1 more

#
Hi,

I'm using dyn.load to load a shared library (compiled from C 
code) into R.  If I dyn.unload it and then dyn.load it again, I 
get an hourglass icon in Rgui (R 1.7.0, Win 2000), and it 
just sits there forever.  I can't press Escape to stop the 
current computation, but I can close Rgui without resorting to 
using the Task Manager.

Is it a problem with my use of R_alloc?  Do I need something 
like R_cleanup?  Or is it a problem with dyn.load?

I'll demonstrate how I compile a C file, HelloFromC.C into a 
shared library, HelloFromC.dll and then load it into R.

HelloFromC.c
------------
#include <R.h>
#include <Rinternals.h>
#include <R_ext/Rdynload.h>
#include <R_ext/Memory.h>
#include <R_ext/Applic.h>
#include <stdio.h>

void HelloFromC(char **result)
{
   *result = (char *) R_alloc(20,sizeof(char));
   sprintf(*result,"Hello from C!"); 
}

static const
R_CMethodDef CEntries[] = {
{"HelloFromC",(DL_FUNC) &HelloFromC,1},
{NULL,NULL,0}
};

void R_init_HelloFromC(DllInfo *info)
{
    R_registerRoutines(info,CEntries,NULL,NULL,NULL);
}

----------------------------------------------------------------
c:\james\HelloFromC> Rcmd SHLIB HelloFromC
making HelloFromC.d from HelloFromC.c
gcc   -IC:/JAMES/rw1070/src/include -Wall -O2   -c HelloFromC.c 
-o HelloFromC.o
ar cr HelloFromC.a *.o
ranlib HelloFromC.a
gcc  --shared -s  -o HelloFromC.dll HelloFromC.def HelloFromC.a  
-LC:/JAMES/rw1070/src/gnuwin32  -lg2c -lR
-----------------------------------------------------------------

Now in R 1.7.0...
-----------------
[1] "Hello from C!"
This is where it freezes.

Any suggestions?

Regards,
James
#
As there is AFAIK no way to unregister entry points, you cannot safely
unload a DLL with registered entry points (which is what your code appears
to do).  So if you want to do this, don't register them,

Package tcltk does unload its DLL (so the Tcl/Tk dlls get released) if 
detached, and so was not modified to register.

Until un-registration is provided, I would not use the registration 
mechanisms during development.
On Fri, 16 May 2003, James Wettenhall wrote:

            

  
    
#
Prof Brian Ripley wrote:
This is not true.  The unloading of a shared library automatically
unregisters the entry points (the routine Rf_freeDllInfo in
Rdynload.c). So using the registration is not a problem.

Checking this on both my Linux and Windows boxes running 1.7 patched
doesn't cause any problems.  Adding a static variable to the
HelloFromC routine and both incrementing it and adding its value to
the returned string in each call illustrates that when a second
dyn.load() call is made, a new version of the library comes in.

So I can't reproduce the problem directly from the commands.
Something that comes to mind is that another process has got a lock on
the file. But I don't see that as likely.
This is *NOT* a necessary precaution.  Registration has the potential
to improve this situation rather than diminishing it. So please don't
let this discourage people from using registration.

 D.

  
    
#
Thank you for the corrections -- my knowledge is clearly out of date, but 
I have been bitten by this in the past.

Apologies for misleading people.
On Fri, 16 May 2003, Duncan Temple Lang wrote:

            

  
    
#
Duncan Temple Lang <duncan at research.bell-labs.com> writes:
Possibly completely unrelated, but Windows does the strangest things
with file locks -- I've been having problems with this (working with
files cross-platform (from Linux and Windows vis 2k terminal servier
on the same fileserver), and finding unreleased locks every so often. 

best,
-tony