Dear R-devel,



Some time ago I started a thread that boiled down to clean-up actions after non-local exits in R, see below. I wonder if there has been any progress on this? R-ext 2.6.1 doesn't say much on the subject.



How, for example, do people deal with a situation where their C (C++) function opens a file and then receives a signal or  longjump-s on error(), how do they make sure the file is eventually closed?



Thanks,

Vadim



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@stat.uiowa.edu<mailto:luke@stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > 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@stat.uiowa.edu<mailto:luke@stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > > >
> > > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> > > >
> > > > > > From: Luke Tierney [mailto:luke@stat.uiowa.edu<mailto:luke@stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > > ...
> > > > > >
> > > > > > 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@stat.math.ethz.ch<mailto:R-help@stat.math.ethz.ch?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted> 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<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@stat.uiowa.edu<mailto:luke@stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>
> > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu<http://www.stat.uiowa.edu/>
> >
> >
> >
>
> ______________________________________________
> R-help@stat.math.ethz.ch<mailto:R-help@stat.math.ethz.ch?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted> 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<http://www.r-project.org/posting-guide.html>
>

--
Luke Tierney


	[[alternative HTML version deleted]]

