Laurent Gautier wrote:
> No need. Because of the GIL, a C call has to return before any thread
> can proceed (or so I think - I have tried or investigated this in
> details at the moment).
edit: I have *not* tried.
> laurent oget wrote:
>> But in any case no global between process locking throu
No need. Because of the GIL, a C call has to return before any thread
can proceed (or so I think - I have tried or investigated this in
details at the moment).
laurent oget wrote:
> But in any case no global between process locking through a file lock or
> something of that sort, right?
>
> L
But in any case no global between process locking through a file lock or
something of that sort, right?
L
2009/1/12 Laurent Gautier
> Two things.
>
> rpy2.rinterface if making sure that R gets initialized only once
> (otherwise everything breaks), which translates at the level of
> rpy2.robj
Two things.
rpy2.rinterface if making sure that R gets initialized only once
(otherwise everything breaks), which translates at the level of
rpy2.robjects as a singleton pattern (r singleton of class R).
For evaluating R code, the locking is somehow ensured by Python's
GIL. All access
Does Rpy2 use any systemwide locking to ensure that only one instance is
running at a given time or is this only a process-wide logging to make sure
only one thread within one process is using R?
Thanks,
Laurent
--
This S
