On 13 February 2012 at 11:09, Darren Cook wrote:
| > I took it to mean it forks per connection. The quote below is talking
| > about threads in a client application sharing a connection to an Rserve
| > server. Assuming I didn't misunderstood that much, it implies R can
| > handle non-eval command
> I took it to mean it forks per connection. The quote below is talking
> about threads in a client application sharing a connection to an Rserve
> server. Assuming I didn't misunderstood that much, it implies R can
> handle non-eval commands in parallel, ...
Ah, I see my misunderstanding: eval()
Hi Darren,
On 12 February 2012 at 18:13, Darren Cook wrote:
| > | I found [2], suggesting that this is okay for RServe. Implying it would
| > | be okay for RInside too?
| >
| > At present, Rserve is set up to fork (on OS X and Linux)...
|
| I took it to mean it forks per connection. The quote b
> | I found [2], suggesting that this is okay for RServe. Implying it would
> | be okay for RInside too?
>
> At present, Rserve is set up to fork (on OS X and Linux)...
I took it to mean it forks per connection. The quote below is talking
about threads in a client application sharing a connection
On 12 February 2012 at 11:47, Darren Cook wrote:
| I think the correct approach for R is to have a single global instance
| (or on the stack in main()) (e.g. [1]).
|
| If your application is multi-threaded, what extra steps do you need to
| take? Does every call to the RInside object have to be p
I think the correct approach for R is to have a single global instance
(or on the stack in main()) (e.g. [1]).
If your application is multi-threaded, what extra steps do you need to
take? Does every call to the RInside object have to be protected by a
mutex? Or, I wonder if some read-only accesses
