AFAIK it's all much simpler that you think. Technically common blocks are just FORTRAN's slightly complicated way to declare and access global variables. They have nothing to do with IPC - each process is loading SOs in its own virtual memory, so other processes are irrelevant (the actual implementation is usually COW which has the same effect but is more memory-efficient -- but this doesn't change the semantics). The confusion may come from the fact that in Fortran literature "shared" has a different meaning (shared between modules of the same program = process) than in IPC (shared across processes).
Cheers, Simon On May 9, 2011, at 10:26 AM, Paul Gilbert wrote: > Thanks to everyone that replied to this (some offline). I should have been a > bit clearer about my question. I did realize that it does work sometimes. My > worry is whether it can be expected to work reliably. In this respect, I am > aware of three specific reasons for concern: i/ if common data is swapped out > does it get swapped back in ok (e.g. the data segment does not get compressed > because it should be all zero or NA); ii/ would R release memory (garbage > collect) between different calls to the fortran; and iii/ does another R > process using the same package get its own copy of the dll/.so data segment. > > I have been relatively well convinced about the first two i/ swap treats this > as user data and preserves it (though some OSes might prevent writing to the > code segment); and ii/ R does not garbage collect the dll/.so so the data > segment is safely (or otherwise) under fortran's control. > > I am less certain about the third. This seems to depend on sharing the data > segment of the shared object within a process but not sharing it between > processes. That is, each process has its own data block even though different > processes might or might not share the code block. Googling turned up > discussions about using common blocks for inter-process communications, but I > did not find the conclusion. It seems pretty clear that for the common block > to be reliable in the sense I have in mind, inter-process communication would > be prevented. > > I am a bit concerned that the answer may be compiler and/or OS dependent. > This is well outside of my expertise, so assurances would be greatly > appreciated. > > Paul > >> -----Original Message----- >> From: b.rowling...@googlemail.com [mailto:b.rowling...@googlemail.com] >> On Behalf Of Barry Rowlingson >> Sent: May 8, 2011 3:44 AM >> To: Paul Gilbert >> Cc: r-devel@r-project. org >> Subject: Re: [Rd] fortan common block >> >> On Fri, May 6, 2011 at 4:04 PM, Paul Gilbert >> <pgilb...@bank-banque-canada.ca> wrote: >>> Is it possible in R to call a fortran routine that sets variables in >> a common block and expect the values to persist when a call is made >> from R to a second routine that uses the common block? >>> >>> If not (as I suspect), is it possible to use a common block in a >> group of routines that are used together, for as long the routines do >> not return to R? >> >> Simple test seems to confirm it. Here's some 'tran with a setter and a >> getter: >> >> comchk.f: >> >> subroutine bar(n) >> common /c/ i >> i=n >> end >> >> subroutine geti(j) >> common /c/ i >> j = i >> end >> >> R CMD SHLIB comchk.f >>> dyn.load("comchk.so") >> >>> .Fortran("bar",as.integer(9)) >> [[1]] >> [1] 9 >> >>> .Fortran("geti",as.integer(-1)) >> [[1]] >> [1] 9 >> >> Barry > ==================================================================================== > > La version française suit le texte anglais. > > ------------------------------------------------------------------------------------ > > This email may contain privileged and/or confidential in...{{dropped:26}} > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
