[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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._