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). 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" ?) 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] > > ------------------------------------------------------------------------- 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
