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:[EMAIL PROTECTED] 
> 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:[EMAIL PROTECTED]
> > > 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:[EMAIL PROTECTED]
> > > > > 
> > > > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> > > > > 
> > > > > > > From: Luke Tierney [mailto:[EMAIL PROTECTED]
> > > > ...
> > > > > > > 
> > > > > > > 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.
> > > > 
> > > > ______________________________________________
> > > > [EMAIL PROTECTED] 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:      
> [EMAIL PROTECTED]
> > > Iowa City, IA 52242                 WWW:  
> http://www.stat.uiowa.edu
> > > 
> > > 
> > >
> > 
> > ______________________________________________
> > [EMAIL PROTECTED] 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:      [EMAIL PROTECTED]
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
> 
> 
>

______________________________________________
[EMAIL PROTECTED] 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

Reply via email to