What does the lack of multithreading mean?

Jan 20, 2014 at 10:39 AM
There's alot of talking about the lack of multithreading in R. I'm a long time R-programmer (under Linux) and I'm trying to up my game by involving the general C# devlopers at my office. However, I can't really understand what the lack of multithreading actually means. If I develop a standard webb-application that use R-enhanced data via R.NET, for my 12 clients, how will they notice that R is not multithreded? Can only one of them use the app at the time? Will the app be slow?

Feb 3, 2014 at 7:10 AM

I started a blog post taking stock of the situation with respect to ASP.NET and in relation to limitations of the R engine. But this is not finished, so meanwhile a summary. Note that I do not claim to be 100% sure of some of the following points, but to the best of my knowledge (very limited with ASP.NET).
  • R.NET and the native R engine run in the same process as the application.
  • This can host only one instance of an R session, because there can be only one per process (due to R itself)
  • so with multiple users accessing via a web app the same back end process is not advisable (they would share the same workspace, at best!)
  • I understand that you can set up the R engine to hopefully work from multiple threads , so long as the thread calls are not concurrent. Not of great value.
  • There are multiple reports of ASP.NET with R.NET as back-end showing issues: I would personally not consider such setups ready for production.
being in-process R.NET has (or will have) good throughput performance for data exchange between .NET and R.

I assume that for obvious safety reasons it would be a good idea to isolate the user's R instances in a web portal scenario; I assume the best way is to run each instance in a separate process. R.NET is not aimed at handling multiple processes, so you may want to consider alternatives or complementary solutions.

Hope this helps.