[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