[Rd] multi-threaded R current status?

Warnes, Gregory R gregory_r_warnes@groton.pfizer.com
Fri, 12 Apr 2002 16:01:44 -0400



> -----Original Message-----
> From: Duncan Temple Lang [mailto:duncan@research.bell-labs.com]
> Sent: Friday, April 12, 2002 3:26 PM
> To: Warnes, Gregory R
> Cc: 'R-devel@stat.math.ethz.ch'
> Subject: Re: [Rd] multi-threaded R current status?
> 
> 
> I plan to attack this in mid May unless Luke or others get there
> first.  As I have mentioned before, making the R engine reentrant
> and/or thread-safe will probably not be all that is needed for your
> purposes, and fixing the packages, especially those with native (C,
> C++ & Fortran) code is also necessary. That is why I have been working
> on a tool that aids in the task of removing the global variables.

Thanks for the status report.  I'm a firm believer in creating tools to
automate pesky repetitive tasks.

Once the core of R is reentrant/thread-safe, perhaps it would be possible to
get 90% of the way to fully reentrant/thread-safe by modifying  .C /
.Fortran / friends to include a lock that prevent more than one thread at a
time from accessing functions within the same library (unless, of course,
the library is flagged as thread-safe.)

> Also, it may be prudent to prioritize an adequate security model in
> your application over allowing concurrent intrusions :-)

Yes, I've already been thinking about security.  For the moment, I'm
building this tool strictly for trusted environments where security
shouldn't be a problem, and I'm not directly exposing R commands to the end
user.  

Still, I'm already running the server as 'nobody' to lessen the potential
for trouble, and I've been considering how to run this within a chroot jail
which contains only the necessary files to run R.   

R has a *lot* of features that allow access to the underlying system and
that could potentially be used to do nasty things, particularly if the user
is allowed to provide arbitrary R code.  Of course, so do all of our
favorite CGI languages.  That's part of what makes them useful ;^) 

-Greg

> 
>  D.
> 
> Warnes, Gregory R wrote:
> > 
> > Hi All,
> > 
> > What is the current status of removing the global variables 
> etc that is
> > required to permit multi-threading R?
> > 
> > I'm developing a web application tool for/using R, python 
> (www.python.org),
> > and Zope (www.zope.org), and it would be really convenient 
> if I could use
> > something like RPy to communicate with several concurrent R 
> sessions,
> > preferably within the same process space.  
> > 
> > -Greg
> > 
> > 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> -.-.-.-.-.-.-.-.-
> > r-devel 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-devel-request@stat.math.ethz.ch
>
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
_._

-- 
_______________________________________________________________

Duncan Temple Lang                duncan@research.bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-3217
700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
Murray Hill, NJ  07974-2070       
         http://cm.bell-labs.com/stat/duncan


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._