Skip to content

R as a daemon?

5 messages · kmself@ix.netcom.com, MJ Ray, Brian Ripley

Original
MJ Ray
# 
kmself at ix.netcom.com writes:
[...]
I intend to work on a similar thing from Perl for release 5 of Rcgi,
but that's a little way off just yet.  (Release 4 should be out this
week.)  The benefits of this are obvious: one of the heaviest bits of
Rcgi is the repeated start-up of R; if maybe not as great as first
thought: after the first start, most of R will be cached in memory if
you have a reasonable amount and there's a performance loss from the
extra housekeeping.

My first thought is to connect it to a local socket via a process
doing access control, some stupidity checking (such as not passing
EOFs on to R) and housekeeping.  Is that sane?
kmself@ix.netcom.com
#
on Wed, Jan 03, 2001 at 11:05:46AM +0000, MJ Ray (mjr at stats.mth.uea.ac.uk) wrote:
EOFs were my first concern.  Keeping the workspace clean my second.

If the daemon is serving requests from multiple clients, you have to
start thinking about security models.  Otherwise, an option would be to
create a per-client bidirectional client.  I think the "persistant
companion process" model is the way I'd like to fly.  Not really a true
daemon, more a helper app.  Simplifies the problem and should suffice.
Brian Ripley
#
On 3 Jan 2001, MJ Ray wrote:

            

      
      
      
    

        
That's been done a few times.  R --slave is there for such purposes: just
connect stdin and stdout/err to pipes, feed a command to stdin and read
the output on stdout (if any), watching that you send complete
expressions.  As of 1.2.0 you can embed Unix R (you have been able to do
so for ages on Windows) and that might be a neater solution.

For an cgi version I would be worried about statefulness.
How are you going to stop one command doing something (overwriting
system functions, for example) that does not affect later ones
submitted by other people?   This applies to DCOM servers etc too,
but there one usually has more idea of what might happen.

There are more possibilities using Omegahat componentry: look on
www.omegahat.org.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      MJ Ray
    

    

      
      #
    

  


  

      
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

            

      
      
      
    

        
How do you mean "embed"?  Sorry for naivity on this, but I've only
done that within Gnome so far.  Just a link would be fine.

            

      
      
      
    

        
As kmself pointed out, the sensible way to do this is by giving each
client their own R.  This makes sense from two performance ways: the
same client is likely to send multiple requests in succession; if they
break their session by doing something "silly", it's their own fault
and affects only them.

            

      
      
      
    

        
I'm confused.  Although the front page says you can call Perl from R
_and vice-versa_, only calling Perl from R seems to be documented at
first glance.  The python one looks more useful in that way.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 3 Jan 2001, MJ Ray wrote:

        

            

      
      
      
    

        
See http://developer.r-project.org/embedded.html

NEWS says

    o   Preliminary support for building R as a shared library (`libR')
        under Unix.  Use configure with option `--enable-R-shlib' or do
        `make libR' in directory `src/main' to create the shared
        library.
        
        There is also a linker front-end `R CMD LINK' which is useful
        for creating executable programs linked against the R shared
        library.

and that's about all there is.

The idea is that you can make a shared library version of R. libR.so, and
link your application against it.  There are even some examples, but I
don't know of a link to those.

            

      
      
      
    

        
How can cgi identify the client?  You may have fail-safe ways of doing so,
but there is nothing to stop me having two applets in one browser each
talking to the cgi-server, so they will not be straightforward ones.
Perhaps I am thinking much more generally than you intend to implement.

            

      
      
      
    

        
I thought about CORBA, or Perl. (I believe you can go both ways, but if
you tell Duncan what is missing information he is happy to provide it, in
my experience.)  But I would try embedding R first, and you may need to
ask Duncan Temple Lang for his test examples.