I fully agree with Kevin. Front-ends can always use pthread_atfork() to close
descriptors and suspend threads in children.
Anyone who thinks you can use PSOCK clusters has obviously not used mclappy()
in real applications - trying to save the workspace and restore it in 20 new
processes is not
I think it's worth saying that mclapply() works as documented: it
relies on forking, and so doesn't work well in environments where it's
unsafe to fork. This is spelled out explicitly in the documentation of
?mclapply:
It is strongly discouraged to use these functions in GUI or embedded
environmen
Hi Inaki,
> "Performant"... in terms of what. If the cost of copying the data
> predominates over the computation time, maybe you didn't need
> parallelization in the first place.
Performant in terms of speed. There's no copying in that example
using `mclapply` and so it is significantly faster
On Fri, 12 Apr 2019 at 21:32, Travers Ching wrote:
>
> Just throwing my two cents in:
>
> I think removing/deprecating fork would be a bad idea for two reasons:
>
> 1) There are no performant alternatives
"Performant"... in terms of what. If the cost of copying the data
predominates over the comp
Just throwing my two cents in:
I think removing/deprecating fork would be a bad idea for two reasons:
1) There are no performant alternatives
2) Removing fork would break existing workflows
Even if replaced with something using the same interface (e.g., a
function that automatically detects vari
On Thu, 11 Apr 2019 at 22:07, Henrik Bengtsson
wrote:
>
> ISSUE:
> Using *forks* for parallel processing in R is not always safe.
> [...]
> Comments?
Using fork() is never safe. The reference provided by Kevin [1] is
pretty compelling (I kindly encourage anyone who ever forked a process
to read i
