[R] mkChar can be interrupted
Luke Tierney
luke at stat.uiowa.edu
Tue Jun 15 04:45:58 CEST 2004
On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> 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.
Interrupts are not the issue. The issue is making sure that cleanup
actions occur even if there is a non-local exit. A solution that
addresses that issue will work for any non-local exit, whether it
comes from an interrupt or an exception. So you don't have to put up
with anything if you approach this the right way,
Currently there is no user accessible C level try/finally mechanism
for insuring that cleanup code is executed during a non-local exit.
We should make such a mechanicm available; maybe one will make it into
the next major release.
For now you have two choices:
You can create an R level object and attach a finalizer to the object
that will arrange for the GC to close the file at some point in the
future if a non-local exit occurs. Search developer.r-project.org for
finalization and weak references for some info on this.
One other option is to use the R_ToplevelExec function. This has some
drawbacks since it effectively makes invisible all other error
handlers, but it is an option. It is also not officially documented
and subject to change.
> 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?
R_alloc is stack-based; the stack is unwound on a non-local exit, so
this is released on regular exits and non-local ones. It uses R
allocation, so it could itself cause a non-local exit.
Calloc is like calloc but will never return NULL. If the allocation
fails, then an error is signaled, which will result in a non-local
exit. If the allocation succeeds, you are responsable for calling
Free.
luke
> > -----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
> >
> >
> >
>
> ______________________________________________
> 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
More information about the R-help
mailing list