Hi Laurent,
It does seem desirable to include an component with Rpy for handling
multi-threading and R. We should think a bit about the right way to
implement this. I think it would be good to make sure and use an code
implementation that is a good match for the right conceptual model. To this
end, perhaps we should implement an ³R thread object² which has exclusive¹
access to R. All of the ³other² threads communicate with R through this
separate R thread object.
..
-G
On 6/26/08 11:42AM , "Laurent Gautier" <[EMAIL PROTECTED]> wrote:
> Speaking of which, it would be nice if rpy was shipped with a vanilla
> locking mechanism.
>
> R remaining probably thread-unsafe for the foreseeable future, I was
> thinking of having something
> like a two-locks mechanism that would lock R and release Python's GIL
> whenever an access to R is made.
>
> The expected benefits are:
> - explicit error message when someone tries a multithreaded approach
> (currently, I suspect that
> what is happening in such a case is unpredictable)
> - ability to have some level of parallelization where python-ish
> things can still be done while R is busy (useful for GUIs, or for
> cases where preparing a next batch of data can be done by python while
> R is still computing on the current batch)
> The downside I am seeing is it will make the handling of Python
> callbacks (python functions passed to R functions as arguments)
> complicated (if possible).
>
> Ideas, or help, on the matter are welcome.
>
>
> L.
>
>
>
>
> 2008/6/26 Gregory Warnes <[EMAIL PROTECTED]>:
>> >
>> > Hello Laurent,
>> >
>> > The R system itself is not thread safe, and has quite a bit of persistent
>> > state. Therefore if you want to use R from multiple threads, you will need
>> > to arrange to have a single thread interact with R at a time via
>> appropriate
>> > locking or delegation.
>> >
>> > -G
>> >
>> >
>> > On 6/26/08 11:17AM , "laurent oget" <[EMAIL PROTECTED]> wrote:
>> >
>> > fellows,
>> >
>> > did anybody experiment with running rpy in 2 threads?
>> >
>> > ________________________________
>> > -------------------------------------------------------------------------
>> > Check out the new SourceForge.net Marketplace.
>> > It's the best place to buy or sell services for
>> > just about anything Open Source.
>> > http://sourceforge.net/services/buy/index.php
>> >
>> > --
>> > Gregory R. Warnes, Ph.D
>> > Program Director
>> > Center for Computational Arts, Sciences, and Engineering
>> > University of Rochester
>> >
>> > Tel: 585-273-2794
>> > Fax: 585-276-2097
>> > Email: [EMAIL PROTECTED]
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Check out the new SourceForge.net Marketplace.
>> > It's the best place to buy or sell services for
>> > just about anything Open Source.
>> > http://sourceforge.net/services/buy/index.php
>> > _______________________________________________
>> > rpy-list mailing list
>> > rpy-list@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/rpy-list
>> >
>> >
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> rpy-list mailing list
> rpy-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rpy-list
>
--
Gregory R. Warnes, Ph.D
Program Director
Center for Computational Arts, Sciences, and Engineering
University of Rochester
Tel: 585-273-2794
Fax: 585-276-2097
Email: [EMAIL PROTECTED]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
