Simon Thanks. It is not the first time things are simpler than I think. On the other hand, there have also been a number of occasions when they are not as simple as I think.
Paul > -----Original Message----- > From: Simon Urbanek [mailto:simon.urba...@r-project.org] > Sent: May 9, 2011 11:48 AM > To: Paul Gilbert > Cc: r-devel@r-project. org > Subject: Re: [Rd] fortan common block > > 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 > > > > ==================================================================================== 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
