guidance on starting/stopping CLRserver and using .Net-bridge in a package

[mkoohafkan]

First, thank you for a developing this awesome solution for accessing .NET from R and Python.

I'm looking for documentation or best practices guidance on using RDotNet and the .Net-Bridge in an R package. My current strategy is to use .cinit in the .onLoad() namespace hook to spin up the CLRServer and load the necessary DLL (recognizing that this could cause conflicts with other packages that also use CLRServer, but the solution to #4 would resolve that). What's not clear to me is what I should do when the R session is closed or the package is unloaded. Is there a command to quit the server? Is there any cleanup I need to do to delete objects created by .cnew? Some additional guidance documents would be helpful.

[tr8dr]

Hi very good questions:

1. if you used the bridge during an R session and no longer using the objects, once the variables are unbound or overridden or the scope exits in R, the CLR side will free the objects.
   • i.e. if R's GC runs, I rigged to send messages to the CLR server to remove those objects.
   • R has a very basic GC capabilities that responds to variable overwrite, loss of scope, etc.
2. As for quitting the server, on unix I use pkill -f CLR. Ideally I should add a ``.cshutdown()``` or something like that, to send a poison pill to the server. I don't have anything like that currently. On windows you can kill with the task manager.
   • I usually leave it running as will tend to use in other sessions
3. In terms of forcing R to delete an object:
   • obj <- .cnew ("....")
   • obj <- NULL or some other value OR
   • rm(obj)

[mkoohafkan]

Great, thanks for the info. I think that in order to safely integrate rDotNet into a package, we would need to have both a .cshutdown (and/or a per-thread equivalent) and the ability to load/unload DLLs on a per-thread basis as per #4. Would this be achievable for the next release of the package?