[Rd] fortan common block

[Paul Gilbert]

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.urbanek at r-project.org]
> Sent: May 9, 2011 11:48 AM
> To: Paul Gilbert
> Cc: r-devel at 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.rowlingson at googlemail.com
> [mailto:b.rowlingson at googlemail.com]
> >> On Behalf Of Barry Rowlingson
> >> Sent: May 8, 2011 3:44 AM
> >> To: Paul Gilbert
> >> Cc: r-devel at r-project. org
> >> Subject: Re: [Rd] fortan common block
> >>
> >> On Fri, May 6, 2011 at 4:04 PM, Paul Gilbert
> >> <pgilbert at 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 at 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}}