thr3ads.net - R help - [R] mkChar can be interrupted [Jun 2004]

If this information is useful, please help other people find it:
Share via:

Vadim Ogranovich

2004-Jun-14 18:55 UTC

[R] mkChar can be interrupted

Hi,
 
As was discussed earlier in another thread and as documented in R-exts
.Call() should not be interruptible by Ctrl-C. However the following
code, which spends most of its time inside mkChar, turned out to be
interruptible on RH-7.3 R-1.8.1 gcc-2.96:
 
 
#include <Rinternals.h>
#include <R.h>

SEXP foo0(const SEXP nSexp) {
  int i, n;
  SEXP resSexp;

  if (!isInteger(nSexp))
    error("wrong arg type\n");

  n = asInteger(nSexp);
  resSexp = PROTECT(allocVector(STRSXP, n));
    
  Rprintf("!!!time to interrup!!!\n");
  for (i=0; i<n; ++i) {
    SET_STRING_ELT(resSexp, i, mkChar("foo"));
  }

  Rprintf("end mkChar\n");
  UNPROTECT(1);
    
  return R_NilValue;
}



# invoke 'foo0' and give it an argument large enough to let you type
Ctrl-C
# double the argument if you see "end mkChar" and do it again
:-)> x <- .Call("foo0", as.integer(1e7))!!!time to interrup!!!
> 
> version         _                
platform i686-pc-linux-gnu
arch     i686             
os       linux-gnu        
system   i686, linux-gnu  
status                    
major    1                
minor    8.1              
year     2003             
month    11               
day      21               
language R                


Thanks,
Vadim

Luke Tierney

2004-Jun-14 20:29 UTC

head link

[R] mkChar can be interrupted

Not sure why you think this suggest mkChar can be interrupted.

If you want to figure out how interrupt handling works on unix, run
under gdb and single step from the signal to the next point where
R_CheckUserInterrupt is called.  You should find that the signal
handler sets a flag and that flag is checked at various safe points 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.

As mentioned in a reply in another thread, interrupt handling is one
aspect of R internals that is still evolving.  Among other things, we
will need to make changes as we improve support for other event loops.
[In applications with graphical interfaces signals are not the right
way to deal with user interruption (in particular on operating systems
that don't support proper signals)].

Best,

luke

On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> Hi,
>  
> As was discussed earlier in another thread and as documented in R-exts
> .Call() should not be interruptible by Ctrl-C. However the following
> code, which spends most of its time inside mkChar, turned out to be
> interruptible on RH-7.3 R-1.8.1 gcc-2.96:
>  
>  
> #include <Rinternals.h>
> #include <R.h>
> 
> SEXP foo0(const SEXP nSexp) {
>   int i, n;
>   SEXP resSexp;
> 
>   if (!isInteger(nSexp))
>     error("wrong arg type\n");
> 
>   n = asInteger(nSexp);
>   resSexp = PROTECT(allocVector(STRSXP, n));
>     
>   Rprintf("!!!time to interrup!!!\n");
>   for (i=0; i<n; ++i) {
>     SET_STRING_ELT(resSexp, i, mkChar("foo"));
>   }
> 
>   Rprintf("end mkChar\n");
>   UNPROTECT(1);
>     
>   return R_NilValue;
> }
> 
> 
> 
> # invoke 'foo0' and give it an argument large enough to let you
type
> Ctrl-C
> # double the argument if you see "end mkChar" and do it again :-)
> > x <- .Call("foo0", as.integer(1e7))
> !!!time to interrup!!!
> 
> > 
> > version
>          _                
> platform i686-pc-linux-gnu
> arch     i686             
> os       linux-gnu        
> system   i686, linux-gnu  
> status                    
> major    1                
> minor    8.1              
> year     2003             
> month    11               
> day      21               
> language R                
> 
> 
> Thanks,
> Vadim
> 
> ______________________________________________
> 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

Vadim Ogranovich

2004-Jun-14 22:21 UTC

head link

[R] mkChar can be interrupted

> -----Original Message-----
> From: Luke Tierney [mailto:luke at stat.uiowa.edu] 
> Sent: Monday, June 14, 2004 1:30 PM
> To: Vadim Ogranovich
> Cc: R-Help
> Subject: Re: [R] mkChar can be interrupted
> 
> Not sure why you think this suggest mkChar can be interrupted.
> 
> If you want to figure out how interrupt handling works on 
> unix, run under gdb and single step from the signal to the 
> next point where R_CheckUserInterrupt is called.  You should 
> find that the signal handler sets a flag and that flag is 
> checked at various safe points 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?

To make sure, I am not trying to enable or handle interrupts. On the
contrary, I want them to be disabled for the duration of .Call, which is
what I thought R was supposed to do for me. I am surprised it didn't.

As to why I singled out mkChar, well, strictly speaking it is
'SET_STRING_ELT(resSexp, i, mkChar("foo"))' where the
interrupt somehow
goes through. But SET_STRING_ELT is much faster than mkChar so I guessed
that it must be mkChar.
Anyway, be it SET_STRING_ELT or mkChar, the interrupt should have been
blocked.


As an additional check I tried to interrupt right before and right after
  for (i=0; i<n; ++i) {
    SET_STRING_ELT(resSexp, i, mkChar("foo"));
  }
but the interrupt was rightfully blocked.


I understand that .Call blocks interrupts, but it seems that very
primitive functions like SET_STRING_ELT, mkChar can decide to handle
them. This is surprising and I think my conjecture is wrong, but how
else to explain that I was able to interrupt 'foo0'?

Thanks,
Vadim
> 
> As mentioned in a reply in another thread, interrupt handling 
> is one aspect of R internals that is still evolving.  Among 
> other things, we will need to make changes as we improve 
> support for other event loops.
> [In applications with graphical interfaces signals are not 
> the right way to deal with user interruption (in particular 
> on operating systems that don't support proper signals)].
> 
> Best,
> 
> luke
> 
> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> 
> > Hi,
> >  
> > As was discussed earlier in another thread and as 
> documented in R-exts
> > .Call() should not be interruptible by Ctrl-C. However the 
> following 
> > code, which spends most of its time inside mkChar, turned out to be 
> > interruptible on RH-7.3 R-1.8.1 gcc-2.96:
> >  
> >  
> > #include <Rinternals.h>
> > #include <R.h>
> > 
> > SEXP foo0(const SEXP nSexp) {
> >   int i, n;
> >   SEXP resSexp;
> > 
> >   if (!isInteger(nSexp))
> >     error("wrong arg type\n");
> > 
> >   n = asInteger(nSexp);
> >   resSexp = PROTECT(allocVector(STRSXP, n));
> >     
> >   Rprintf("!!!time to interrup!!!\n");
> >   for (i=0; i<n; ++i) {
> >     SET_STRING_ELT(resSexp, i, mkChar("foo"));
> >   }
> > 
> >   Rprintf("end mkChar\n");
> >   UNPROTECT(1);
> >     
> >   return R_NilValue;
> > }
> > 
> > 
> > 
> > # invoke 'foo0' and give it an argument large enough to let 
> you type 
> > Ctrl-C # double the argument if you see "end mkChar" and do 
> it again 
> > :-)
> > > x <- .Call("foo0", as.integer(1e7))
> > !!!time to interrup!!!
> > 
> > > 
> > > version
> >          _                
> > platform i686-pc-linux-gnu
> > arch     i686             
> > os       linux-gnu        
> > system   i686, linux-gnu  
> > status                    
> > major    1                
> > minor    8.1              
> > year     2003             
> > month    11               
> > day      21               
> > language R                
> > 
> > 
> > Thanks,
> > Vadim
> > 
> > ______________________________________________
> > 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
> 
> 
>

Vadim Ogranovich

2004-Jun-14 23:34 UTC

head link

[R] mkChar can be interrupted

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?

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.

Vadim Ogranovich

2004-Jun-15 01:31 UTC

head link

[R] mkChar can be interrupted

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
> 
> 
>

Vadim Ogranovich

2004-Jun-15 03:56 UTC

head link

[R] mkChar can be interrupted

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
> 
> 
>

Seemingly Similar Threads

Search for more seemingly similar threads

R help - Jun 2004 - mkChar can be interrupted

[R] mkChar can be interrupted

[R] mkChar can be interrupted

[R] mkChar can be interrupted

[R] mkChar can be interrupted

[R] mkChar can be interrupted

[R] mkChar can be interrupted

Seemingly Similar Threads