On 6/27/08 8:53AM , "Laurent Gautier" <[EMAIL PROTECTED]> wrote:
> There should definitely be a way to enforce one communication at a time.
>
> Having a thread master that conducts communications with an R process
> would be helpful in helping someone build a multi-threaded application.
>
> What I am wondering is whether this should be the default mode of operation
> (as it might sensibly complexify the simplest thing - particularly
> in the case one is not interested in multithreading).
>
Of course! Keep single threaded access as simple as possible.
>
> What about the following in the begining:
> - have a lock at the C level (to prevent
> current;y-forbidden-but-possible concurrent access to R);
> throws an exception if concurrent access is attempted.
> - build a multi-threads conductor and offer it in a module of rpy
> (may be a class extending Python's "threading.Thread" ?)
>
This makes good sense.
-G
>
> L.
>
>
>
>
> 2008/6/26 Gregory Warnes <[EMAIL PROTECTED]>:
>> > 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]
>> >
>> >
>
--
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
