[Rd] [R] multithreading calling from the rpy Python package

René J.V. Bertin rjvbertin at gmail.com
Fri Oct 20 20:37:40 CEST 2006


> But it still remains to be seen whether the extra work to introduce
> threads is warranted. Will people actually use them in R and will it
> have a significant impact on the computations or simply make writing
> GUIs within R slightly easier to manage?

  If threads can be set up easily, why not? Now that multi-core
machines are becoming more easily available...

It is not just about reducing computation time, btw. Not so long ago,
I was setting up a system in Matlab to do concurrent sampling of a DAQ
and an eye-tracker, and to show and record the sampled data. The DAQ
toolbox fires off its own thread that does the actual sampling and can
be configured to call a Matlab callback function at a predetermined
interval.
The eye-tracker code is single-threaded. If Matlab had been
threadable, I'd have been able to sample the tracker in a different
thread, and not miss out on the data coming in while plotting.

> One of the reasons I am hesitant to use Python as a framework on
> which to build a new system is the "thread-safe but not threadable"
> issue. Also, it is not easily extensible in an object oriented manner

  Well, I didn't mean to suggest that it would the perfect solution.
It seemed like a potentially worthwhile, feasible temporary solution
that would allow at least some multithreading. I don't see how it is
not easily extensible in an OO manner, though. The Python threads I
use *are* objects (and very similar apparently to Java's threading
model).

Best,
René




More information about the R-devel mailing list