From luke at stat.uiowa.edu  Fri Oct 20 22:00:35 2006
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Fri, 20 Oct 2006 15:00:35 -0500 (CDT)
Subject: [Rd] [R] multithreading calling from the rpy Python package
In-Reply-To: <797664590610201137t6e180e3eyd3fe6860b8886145@mail.gmail.com>
References: <797664590610120908k3f8090d4p61a850cf6be60ccc@mail.gmail.com>
	<452E7095.40804@wald.ucdavis.edu>
	<797664590610121012g430c58f1x91756c2437e7510d@mail.gmail.com>
	<F722604B-31E6-43B0-B215-3E3CCB96780F@r-project.org>
	<797664590610200711w46a60957s44cd805ea7909a5b@mail.gmail.com>
	<Pine.LNX.4.64.0610200918560.2751@nokomis.stat.uiowa.edu>
	<45390058.80503@wald.ucdavis.edu>
	<797664590610201137t6e180e3eyd3fe6860b8886145@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0610201455530.2586@itasca2.wildberry.org>

On Fri, 20 Oct 2006, Ren? J.V. Bertin wrote:

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

If it was easy it would have been done along time ago.  And what does
multi-core have to do with Python style threading? Nothing of course
...

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

Yes, concurrent threading as available in Pyton is useful.  Is is
useful enough to justify the effort of those who are going to end up
doing the work (given that there are other things we could also be
working on)?  That is not clear.

Best,

luke

>> 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?
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu


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