[R] mkChar can be interrupted
Vadim Ogranovich
vograno at evafunds.com
Tue Jun 15 05:56:58 CEST 2004
Thank you. This gives hope, I am looking forward to the next major
release.
May I make a wish that the future try/finally mechanism will inlcude
support for C++ exceptions? For example by allowing the programmer to
set an error handler that raises a C++ exception. It should be easy in
error(), but might be a problem in interrupt handlers (I am not an
expert though).
Thanks,
Vadim
> -----Original Message-----
> From: Luke Tierney [mailto:luke at stat.uiowa.edu]
> Sent: Monday, June 14, 2004 7:46 PM
> To: Vadim Ogranovich
> Cc: R-Help
> Subject: RE: [R] mkChar can be interrupted
>
> 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
> > C++ 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