thr3ads.net - R devel - [Rd] About R variable references [Aug 2005]

If this information is useful, please help other people find it:
Share via:

Markku Mielityinen

2005-Aug-17 06:48 UTC

[Rd] About R variable references

Hello Group,

I could use an advice on how SEXP handles work. My aim is to implement a
system where I initially set a few global variables that are used for
communication between C and R code. Then I do some work with R code and
periodically call a function of my own that will update the system
state. Such a design is useful for many purposes (for GUIs to name one).
I am not entirely sure that R can handle such a design but at the moment
I cannot see any reasons why it could not. The problem I have is that
the initially set global variables are not stable. Everything works for
a while but eventually the system gets confused. It seems that the SEXP
references to the state variables and to the callback functions may get
altered and become pointing to some other variables. This will then
rightfully give me the error messages like "attempt to apply
non-function". My (maybe uneducated) guess is that this might have
something to do with R memory management. The variables are connected to
the namespace so a do not think they are removed. Maybe they are moved
is such a way that my SEXP references are not able to follow. As you can
see I am on thin ice here so please feel welcome to step in...

My librtary contains ~20k lines of C code so I would not consider a bug
here out of the question. I have tried to look for one but until now
without success.

My question is: can you see a design flaw here or is everything done
according to R requirements and hence it is likely that there is a bug
in my own code?

One dirty correction I can see but have not tried is to use object names
and findVar but this would make it less flexible (at least IMHO).

I have quickly browsed the forums and the documentation I was able to
find but found no answers.

My system is FC3 with R version >= 2.

There are two snippets of code that hopefully make clear what I am
trying to achieve. The code is provided for illustration purposes only
and I did not try to compile it.

Best regards,
        Markku Mielityinen


#  C CODE
#####################################################################

SEXP myrho = R_GlobalEnv;
SEXP myvariable = R_NilValue;
SEXP myfunction = R_NilValue;

SEXP myinit(SEXP var, SEXP func) {
	myvariable = var;
	myfunction = func;
	return R_NilValue;
}

SEXP myexec(/* probably has some parameters that are omitted in this
example */) {
	int state;
	SEXP thecall;
	
	/* do some work, then set the state and call a callback function
if necessary */
	
	PROTECT(myvariable);
	INTEGER(myvariable)[0] = state;
	UNPROTECT(1);
	if(state) {
		PROTECT(thecall = LCONS(myfunction, LCONS(myvariable,
R_NilValue)));
		eval(thecall, myrho);
		UNPROTECT(1);
	}

	return R_NilValue;
}

########################################################################
########

#  R CODE
#####################################################################

myinit<-function(var,func) .Call("myinit",var,func)
myexec<-function() .Call("myexec")

state<-as.integer(1)
callback<-function(state) { cat(sprintf("You got state
%s\n",state)) }

myinit()
# do some work here and call myexec() periodically...

########################################################################
########

Duncan Temple Lang

2005-Aug-17 07:15 UTC

head link

[Rd] About R variable references

Hi Markku.

  You have correctly diagnosed the problem that the initially
set global variables "are not stable".  In your call
to myinit, you store a C-level reference to the var and func
R objects. But you need to tell R's memory management
that you need to hold onto them.  Otherwise it is entitled
to garbage collect them as it feels fit. 
In the C-code for myinit, you might add calls 

    R_PreserveObject(myfunction)
    R_PreserveObject(myvariable)

that is defined in Rinternals.h. These go after
you assign values to your global variables.

You are PROTECT()'ing these variables only in the call
to myexec.

 D.
 

Markku Mielityinen wrote:> Hello Group,
> 
> I could use an advice on how SEXP handles work. My aim is to implement a
> system where I initially set a few global variables that are used for
> communication between C and R code. Then I do some work with R code and
> periodically call a function of my own that will update the system
> state. Such a design is useful for many purposes (for GUIs to name one).
> I am not entirely sure that R can handle such a design but at the moment
> I cannot see any reasons why it could not. The problem I have is that
> the initially set global variables are not stable. Everything works for
> a while but eventually the system gets confused. It seems that the SEXP
> references to the state variables and to the callback functions may get
> altered and become pointing to some other variables. This will then
> rightfully give me the error messages like "attempt to apply
> non-function". My (maybe uneducated) guess is that this might have
> something to do with R memory management. The variables are connected to
> the namespace so a do not think they are removed. Maybe they are moved
> is such a way that my SEXP references are not able to follow. As you can
> see I am on thin ice here so please feel welcome to step in...
> 
> My librtary contains ~20k lines of C code so I would not consider a bug
> here out of the question. I have tried to look for one but until now
> without success.
> 
> My question is: can you see a design flaw here or is everything done
> according to R requirements and hence it is likely that there is a bug
> in my own code?
> 
> One dirty correction I can see but have not tried is to use object names
> and findVar but this would make it less flexible (at least IMHO).
> 
> I have quickly browsed the forums and the documentation I was able to
> find but found no answers.
> 
> My system is FC3 with R version >= 2.
> 
> There are two snippets of code that hopefully make clear what I am
> trying to achieve. The code is provided for illustration purposes only
> and I did not try to compile it.
> 
> Best regards,
>         Markku Mielityinen
> 
> 
> #  C CODE
> #####################################################################
> 
> SEXP myrho = R_GlobalEnv;
> SEXP myvariable = R_NilValue;
> SEXP myfunction = R_NilValue;
> 
> SEXP myinit(SEXP var, SEXP func) {
> 	myvariable = var;
> 	myfunction = func;
> 	return R_NilValue;
> }
> 
> SEXP myexec(/* probably has some parameters that are omitted in this
> example */) {
> 	int state;
> 	SEXP thecall;
> 	
> 	/* do some work, then set the state and call a callback function
> if necessary */
> 	
> 	PROTECT(myvariable);
> 	INTEGER(myvariable)[0] = state;
> 	UNPROTECT(1);
> 	if(state) {
> 		PROTECT(thecall = LCONS(myfunction, LCONS(myvariable,
> R_NilValue)));
> 		eval(thecall, myrho);
> 		UNPROTECT(1);
> 	}
> 
> 	return R_NilValue;
> }
> 
> ########################################################################
> ########
> 
> #  R CODE
> #####################################################################
> 
> myinit<-function(var,func) .Call("myinit",var,func)
> myexec<-function() .Call("myexec")
> 
> state<-as.integer(1)
> callback<-function(state) { cat(sprintf("You got state
%s\n",state)) }
> 
> myinit()
> # do some work here and call myexec() periodically...
> 
> ########################################################################
> ########
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
https://stat.ethz.ch/pipermail/r-devel/attachments/20050817/35eda213/attachment.bin

Prof Brian Ripley

2005-Aug-17 07:50 UTC

head link

[Rd] About R variable references

R never moves objects in memory, but it may garbage collect them.

What is not clear to me is that you can guarantee that the objects you 
pass in are not copies subject to garbage collection, but then I don't 
know how you are calling your functions.  A way to make sure that your 
pointers remain valid is to PROTECT them etc on assignment.

Using gctorture(TRUE) will probably ensure things break very quickly if 
gc-ing is the problem.

On Wed, 17 Aug 2005, Markku Mielityinen wrote:
> Hello Group,
>
> I could use an advice on how SEXP handles work. My aim is to implement a
> system where I initially set a few global variables that are used for
> communication between C and R code. Then I do some work with R code and
> periodically call a function of my own that will update the system
> state. Such a design is useful for many purposes (for GUIs to name one).
> I am not entirely sure that R can handle such a design but at the moment
> I cannot see any reasons why it could not. The problem I have is that
> the initially set global variables are not stable. Everything works for
> a while but eventually the system gets confused. It seems that the SEXP
> references to the state variables and to the callback functions may get
> altered and become pointing to some other variables. This will then
> rightfully give me the error messages like "attempt to apply
> non-function". My (maybe uneducated) guess is that this might have
> something to do with R memory management. The variables are connected to
> the namespace so a do not think they are removed. Maybe they are moved
> is such a way that my SEXP references are not able to follow. As you can
> see I am on thin ice here so please feel welcome to step in...
>
> My librtary contains ~20k lines of C code so I would not consider a bug
> here out of the question. I have tried to look for one but until now
> without success.
>
> My question is: can you see a design flaw here or is everything done
> according to R requirements and hence it is likely that there is a bug
> in my own code?
>
> One dirty correction I can see but have not tried is to use object names
> and findVar but this would make it less flexible (at least IMHO).
>
> I have quickly browsed the forums and the documentation I was able to
> find but found no answers.
>
> My system is FC3 with R version >= 2.
>
> There are two snippets of code that hopefully make clear what I am
> trying to achieve. The code is provided for illustration purposes only
> and I did not try to compile it.
>
> Best regards,
>        Markku Mielityinen
>
>
> #  C CODE
> #####################################################################
>
> SEXP myrho = R_GlobalEnv;
> SEXP myvariable = R_NilValue;
> SEXP myfunction = R_NilValue;
>
> SEXP myinit(SEXP var, SEXP func) {
> 	myvariable = var;
> 	myfunction = func;
> 	return R_NilValue;
> }
>
> SEXP myexec(/* probably has some parameters that are omitted in this
> example */) {
> 	int state;
> 	SEXP thecall;
>
> 	/* do some work, then set the state and call a callback function
> if necessary */
>
> 	PROTECT(myvariable);
> 	INTEGER(myvariable)[0] = state;
> 	UNPROTECT(1);
> 	if(state) {
> 		PROTECT(thecall = LCONS(myfunction, LCONS(myvariable,
> R_NilValue)));
> 		eval(thecall, myrho);
> 		UNPROTECT(1);
> 	}
>
> 	return R_NilValue;
> }
>
> ########################################################################
> ########
>
> #  R CODE
> #####################################################################
>
> myinit<-function(var,func) .Call("myinit",var,func)
> myexec<-function() .Call("myexec")
>
> state<-as.integer(1)
> callback<-function(state) { cat(sprintf("You got state
%s\n",state)) }
>
> myinit()
> # do some work here and call myexec() periodically...
>
> ########################################################################
> ########
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

Possibly Parallel Threads

Search for more possibly parallel threads

R devel - Aug 2005 - About R variable references

[Rd] About R variable references

[Rd] About R variable references

[Rd] About R variable references

Possibly Parallel Threads