Hi Andreas,
note that with the introduction of ALTREP, as far as I understand, calls
as "simple" as DATAPTR can execute arbitrary code (R or native). Even
without ALTREP, if you execute user-provided R code via Rf_eval and such
on some custom thread, you may end up executing native code of som
Hi Abs,
Re: your last point:
> You made an interesting comment.
>
> > This is not
> > always the desired behavior, because formulas are increasingly used
> > for purposes other than specifying linear models.
>
> Can I ask what these purposes are?
Not sure how relevant these are/what Pavel was
I've been hacking with parallel package for some time and built a
parallel processing framework with it. However, although very rarely,
I did notice "ignoring SIGPIPE signal" error every now and then.
After a deep dig into the source code, I think I found something worth
noticing.
In short, wring
I've been hacking with parallel package for some time and built a
parallel processing framework with it. However, although very rarely,
I did notice "ignoring SIGPIPE signal" error every now and then.
After a deep dig into the source code, I think I found something worth
noticing.
In short, wring
Stepan,
Andreas gave a lot more thought into what you question in your reply. His
question was how you can avoid what you where proposing and have proper
threading under safe conditions. Having dealt with this before, I think
Andreas' write up is pretty much the most complete analysis I have se
This issue has already been addressed in 76462 (R-devel) and also ported
to R-patched. In fact rmChild() is used in mccollect(wait=FALSE).
Best
Tomas
On 5/19/19 11:39 AM, Sun Yijiang wrote:
I've been hacking with parallel package for some time and built a
parallel processing framework with it.
Have read the latest code, but I still don't understand why mc_exit
needs to write zero on exit. If a child closes its pipe, parent will
know that on next select.
Best,
Yijiang
Tomas Kalibera 于2019年5月20日周一 下午10:52写道：
>
> This issue has already been addressed in 76462 (R-devel) and also ported
>
Because that's the communication protocol between the parent and child. There
is a difference between unsolicited exit and empty result exit.
Cheers,
Simon
> On May 20, 2019, at 11:22 AM, Sun Yijiang wrote:
>
> Have read the latest code, but I still don't understand why mc_exit
> needs to wri
Your analysis looks pretty complete to me and your solutions seems
plausible. That said, I don't know that I would have the level of
confidence yet that we haven't missed an important point that I would
want before going down this route.
Losing stack checking is risky; it might be eventually poss
# Proposal
Provide a built-in mechanism for obtaining an identifier for the
current R session, e.g.
> Sys.info()[["session_uuid"]]
[1] "4258db4d-d4fb-46b3-a214-8c762b99a443"
The identifier should be "unique" in the sense that the probability
for two R sessions(*) having the same identifier shoul
I think a machine-specific input, like the MAC address, to the UUID is
essential. S+ used to make a seed for the random number generator based on
the the current time and process ID. A customer complained that all
machines in his cluster generated the same random number stream. The
machines were
11 matches
Mail list logo
