fortan common block

[Paul Gilbert]

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?

Paul
====================================================================================

La version française suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so.

------------------------------------------------------------------------------------

Le présent courriel peut contenir de l'information privilégiée ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre
ordinateur toute copie du courriel reçu.

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Duncan Murdoch-2]

On 06/05/2011 11:04 AM, Paul Gilbert 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?

I think the stats package does this; see src/library/stats/src/ppr.f.  
The Fortran functions don't "know" that R is doing the calling, so
they'll set and read values as if they were called from a Fortran main
program.

Duncan Murdoch

> 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?
>
> Paul
> ====================================================================================
>
> La version française suit le texte anglais.
>
> ------------------------------------------------------------------------------------
>
> This email may contain privileged and/or confidential information, and the Bank of
> Canada does not waive any related rights. Any distribution, use, or copying of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it immediately from
> your system and notify the sender promptly by email that you have done so.
>
> ------------------------------------------------------------------------------------
>
> Le présent courriel peut contenir de l'information privilégiée ou confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
> personne autre que le ou les destinataires désignés est interdite. Si vous recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai Ã
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre
> ordinateur toute copie du courriel reçu.
>
> [[alternative HTML version deleted]]
>
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Sharpie]

Paul Gilbert 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?

Paul

Don't see why not--should be pretty easy to test. Personally, I would use variables in a Fortran 90 module over a common block.

-Charlie

[Barry Rowlingson]

On Fri, May 6, 2011 at 4:04 PM, Paul Gilbert
<[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Paul Gilbert]

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: [hidden email] [mailto:[hidden email]]
> 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
> <[hidden email]> 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}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Simon Urbanek]

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: [hidden email] [mailto:[hidden email]]
>> 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
>> <[hidden email]> 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}}
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[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:[hidden email]]
> 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: [hidden email]
> [mailto:[hidden email]]
> >> 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
> >> <[hidden email]> 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}}
> >
> > ______________________________________________
> > [hidden email] 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}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel