+1 to what Gabor and Ralf said. In this case the memory address can be misleading. My understanding is that the environments in all the processes, 1 parent and 2 child, have the *same* memory address, but once you write to them the operating system makes copies and maps the address to a *different* physical address. This is the copy-on-write UNIX fork model.
The example below shows 3 processes that all use the same address for the environment env1, yet there must be 3 different environments, because env1$x has 3 different values simultaneously. -Clark library(parallel) env1 <- new.env() env1$x = 0 cl <- makeCluster(2, type="FORK") # Now we write to the environment, and env1$x has two distinct values clusterEvalQ(cl, env1$x <- rnorm(1)) # [[1]] # [1] -1.296702 # # [[2]] # [1] -0.4001104 # The environments in the 2 child processes still have the same address, # which is the same as the original address parLapply(cl, 1:4, function(x) capture.output(str(env1))) env1 # The original x is unchanged env1$x stopCluster(cl) On Wed, Sep 12, 2018 at 11:31 AM Ralf Stubner <ralf.stub...@daqana.com> wrote: > On 12.09.2018 20:20, Gábor Csárdi wrote: > > This is all normal, a fork cluster works with processes, that do not > > share memory. > > And if you are after shared-memory parallelism, you can try the 'Rdsm' > package: https://cran.r-project.org/package=Rdsm > > Greetings > Ralf > > -- > Ralf Stubner > Senior Software Engineer / Trainer > > daqana GmbH > Dortustraße 48 > 14467 Potsdam > > T: +49 331 23 61 93 11 > F: +49 331 23 61 93 90 > M: +49 162 20 91 196 > Mail: ralf.stub...@daqana.com > > Sitz: Potsdam > Register: AG Potsdam HRB 27966 P > Ust.-IdNr.: DE300072622 > Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
