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 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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. Also, it may be prudent to prioritize an adequate security model in your application over allowing concurrent intrusions :-) 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 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> -----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 -- Readhttp://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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> -----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 -- Readhttp://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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._