[R] mkChar can be interrupted

[Vadim Ogranovich]

This is disappointing. How on Earth can mkChar know when it is safe or
not to make a long jump? For example if I just opened a file how am I
supposed to close it after the long jump? I am not even talking about
C++ where long jumps are simply devastating... (and this is the language
I am coding in :-( )


Ok. A practical question: is it possible to somehow block
R_CheckUserInterrupt? I am ready to put up with out-of-memory errors,
but Ctrl-C is too common to be ignored.

And I think it makes relevant again the question I asked in another
related thread: how is memory allocated by Calloc() and R_alloc() stand
up against long jumps?

Thanks,
Vadim 



> -----Original Message-----
> From: Luke Tierney [mailto:luke at stat.uiowa.edu] 
> Sent: Monday, June 14, 2004 5:43 PM
> To: Vadim Ogranovich
> Cc: R-Help
> Subject: RE: [R] mkChar can be interrupted
> 
> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> 
> > I am confused. Here is an excerpt from R-exts:
> > 
> > "As from R 1.8.0 no port of R can be interrupted whilst 
> running long 
> > computations in compiled code,..."
> > 
> > Doesn't it imply that the primitive functions like allocVector, 
> > mkChar, etc., which are likely to occur in any compiled code called 
> > via .Call, are not supposed to handle interrupts in any way?
> 
> No it does not.  Read the full context.  It says that if you 
> wite a piece of C code that may run a long time and you want 
> to guarantee that users will be able to interrupt your code 
> then you should insure that R_CheckUserInterrupt is called 
> periodically.  If your code already periodically calls other 
> R code that checks for interrupts then you may not need to do 
> this yourself, but in general you do.
> 
> Prior to 1.8.0 on Unix-like systems the asynchronous signal 
> handler for SIGINT would longjmp to the nearest top level or 
> browser context, which meant that on these sytems any code 
> was interruptible at any point unless it was explicitly 
> protected by a construct that suspended interrupts.  Allowing 
> interrupts at any point meant that inopportune interrupts 
> could and did crash R, which is why this was changed.
> 
> Unless there is explicit documentation to the contrary you 
> should assume that every function in the R API might allocate 
> and might cause a non-local exit (i.e. a longjmp) when an 
> exception is raised (and an interrupt is one of, but only one 
> of, the exceptions that might occur).
> 
> luke
> 
> > Thanks,
> > Vadim
> > 
> > 
> > > From: Luke Tierney [mailto:luke at stat.uiowa.edu]
> > > 
> > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> > > 
> > > > > From: Luke Tierney [mailto:luke at stat.uiowa.edu]
> > ...
> > > > > 
> > > > > Not sure why you think this suggest mkChar can be interrupted.
> > > > > 
> > ...
> > > > > by calls to this function.  I don't believe there are any
> > > such safe
> > > > > points in mkChar, but there are several potential ones
> > > within your
> > > > > example.
> > > > 
> > > > Apart from mkChar I am only calling SET_STRING_ELT. Is this
> > > what you
> > > > mean?
> > > 
> > > You are printing, you have an assignment expression, all of those 
> > > contain points where an interrupt could be checked for.
> > 
> > These are not relevant since Ctrl-C is pressed when the 
> code is inside
> >   for (i=0; i<n; ++i) {
> >     SET_STRING_ELT(resSexp, i, mkChar("foo"));
> >   }
> > 
> > Just look at the way I deliver the signal.
> > 
> > ______________________________________________
> > R-help at stat.math.ethz.ch mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide! 
> > http://www.R-project.org/posting-guide.html
> > 
> 
> --
> Luke Tierney
> University of Iowa                  Phone:             319-335-3386
> Department of Statistics and        Fax:               319-335-3017
>    Actuarial Science
> 241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
> 
> 
>