Displaying 20 results from an estimated 1200 matches similar to: "save.image Non-responsive to Interrupt"
2023 May 02
1
save.image Non-responsive to Interrupt
? Sat, 29 Apr 2023 00:00:02 +0000
Dario Strbenac via R-devel <r-devel at r-project.org> ?????:
> Could save.image() be redesigned so that it promptly responds to
> Ctrl+C? It prevents the command line from being used for a number of
> hours if the contents of the workspace are large.
This is ultimately caused by serialize() being non-interruptible. A
relatively simple way to hang
2019 Dec 06
2
long vector support
All,
At first glance, a recent commit to R-devel (
https://github.com/wch/r-source/commit/2c182014ecc8c2407a89092c9162d86046bd18da)
appears to be related to long vector support. But as Henrik Bengtsson
points out at
https://github.com/HenrikBengtsson/Wishlist-for-R/issues/97#issuecomment-562659134,
writeBin() still prohibits long vectors. Are there any plans to add long
vector support to R
2018 Nov 21
3
[PATCH nbdkit v2 0/3] Rewrite xz plugin as a filter.
v2:
- Fixes a number of bugs in corner cases.
- Uses a 1M block size to fetch from the underlying plugin. This
improves performance considerably.
I also tested this much more thoroughly and can't find any more bugs.
Rich.
2018 Nov 21
5
[PATCH nbdkit 0/2] Rewrite xz plugin as a filter.
Matt asked if xz should really be a filter rather than a plugin. The
answer is yes, of course it should be! That's been something in the
todo file for a while.
The commit converts the xz plugin code into a filter (leaving the
plugin around, but deprecating it).
plugin: nbdkit xz file.xz
filter: nbdkit --filter=xz file file.xz
plugin: # can't be done
filter: nbdkit
2011 Apr 25
3
Interrupting C++ code execution
Hello,
I am writing an R interface for one of my C++ programs. The computations
in C++ are very time consuming (several hours), so the user needs to be
able to interrupt them. Currently, the only way I found to do so is
calling R_CheckUserInterrupt() frequently. Unfortunately, there are
several problems with that:
1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no
2005 Feb 11
1
Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?
On Feb 10, 2005, at 7:38 PM, George W. Gilchrist wrote:
> Today I was running a graduate level stats lab using R and we
> encountered a
> major problem while using the current build of the Cocoa GUI:
>
>> From the GUI:
>> system.time(pbinom(80, 1e5, 806/1e6))
> [1] 14.37 4.94 30.29 0.00 0.00
>>
>
>> From the command line on the same machine:
>>
2019 Jul 31
13
[nbdkit PATCH 0/8] fd leak safety
There's enough here to need a review; some of it probably needs
backporting to stable-1.12.
This probably breaks tests on Haiku or other platforms that have not
been as on-the-ball about atomic CLOEXEC; feel free to report issues
that arise, and I'll help come up with workarounds (even if we end up
leaving a rare fd leak on less-capable systems).
Meanwhile, I'm still working on my
2010 Sep 28
1
checking user interrupts in C(++) code
Hello,
My problem is that I have an extension in C++ that can be quite
time-consuming. I'd like to make it interruptible.
The problem is that if I use the recommended R_CheckUserInterrupt() method I
have no possibility to cleanup (e.g. free the memory).
I've seen an old thread about this, but I wonder if there's a new and
definitive answer.
I just do not understand why a simple
2019 Apr 30
2
Background R session on Unix and SIGINT
Hi All,
I realize that this is not a really nice reprex, but anyone has an
idea why a background R session would "remember" an interrupt (SIGINT)
on Unix?
rs <- callr::r_session$new()
rs$interrupt() # just sends a SIGINT
#> [1] TRUE
rs$run(function() 1+1)
#> Error: interrupt
rs$run(function() 1+1)
#> [1] 2
It seems that the main loop somehow stores the SIGINT it
2014 Feb 03
1
String Vector Encoding
Hello,
I was reading through serialize.c and i couldn't answer something.
In readItem, case CHARSXP, rules exists to adjust the read string for
string encoding.
Q1. I couldn't find where the encoding of the elements of the string vector
are written? Is it when writeItem writes out the attributes of the item?
But i couldn't find encoding in the attributes field
x <-
2019 Apr 30
2
[External] Re: Background R session on Unix and SIGINT
Unfortunately --interactive also makes the session interactive(),
which is bad for me, as it is a background session.
In general, I don't want the interactive behavior, but was wondering
if I could send as SIGINT to try to interrupt the computation of the
background process, and if that does not work, then I would send a
SIGKILL and start up another process. It all works nicely, except for
2019 Apr 30
2
Background R session on Unix and SIGINT
Yeah, I get that they are async.
What happens is that the background process is not doing anything when
the process gets a SIGINT. I.e. the background process is just
listening on its standard input.
AFAICT for an interactive process such a SIGINT is just swallowed,
with a newline outputted to the terminal.
But apparently, for this background process, it is not swallowed, and
it is triggered
2007 Feb 27
1
Checking for user interrupt in a .C() call without without triggering a non-local exit.
Hi,
An R package on which I am working makes a series of very
computationally-intensive and complex .C() calls, that I would like to
make interruptible. However, calling R_CheckUserInterrupt() causes a
non-local exit, so the memory allocated by malloc() is never freed. The
way the code is structured, it might not be practical to replace all the
malloc() calls with R_alloc() calls.
The question
2019 May 19
4
most robust way to call R API functions from a secondary thread
Hi,
As the subject suggests, I am looking for the most robust way to call an (arbitrary) function from the R API from another but the main POSIX thread in a package's code.
I know that, "[c]alling any of the R API from threaded code is ?for experts only? and strongly discouraged. Many functions in the R API modify internal R data structures and might corrupt these data structures if
2019 Apr 30
2
Background R session on Unix and SIGINT
OK, I managed to create an example without callr, but it is still
somewhat cumbersome. Anyway, here it is.
Terminal 1:
mkfifo fif
R --no-readline --slave --no-save --no-restore < fif
Terminal 2:
cat > fif
Sys.getpid()
This will make Terminal 1 print the pid of the R process, so we can
send a SIGINT:
Terminal 3:
kill -INT pid
The R process is of course still running happily.
Terminal 2
2011 Aug 08
1
heavy processing during R_init_XXXXX()
Hi.
Need some advice. I have to load a library during R_init_XXXXX() with
dlopen(). The library file is 23 megabytes long and loads several other
libraries. Everything happens during dlopen() execution, out of control,
and takes around 1 second on first load in a quadcore. Besides, due to
security reasons, a hash of the library file is going to be computed.
Still do not know how long it will
2003 Dec 04
1
Interrupt handling
Hi everyone,
I recently installed R 1.8.1 on some of our machines and noted quickly
that the handling of interrupts has changed since version 1.8.0. Are there
any plans to reintroduce the old behaviour as a feature when compiling R
or even better as a command line option? The problem is that we are
extensively calling C functions from R which take quite a large time to
finish. With the new
2004 Jun 14
5
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))
2012 May 22
1
Capturing signals from within external libs
I have a continuous loop running in an external library that I am calling
from C (R API). This loop is processing events in real time with the
possibility of significant lag between events.
When processing an event, I can make use of R_CheckUserInterrupt, but
while the external library code is waiting on a new event, I don't have an
opportunity to call this - my entry points are only on
2019 Apr 15
2
Feature request: make file.exists interruptable
Hi R developers,
On slow file systems with large lists of files, file.exists can take a long time to run. It would be nice if users could interrupt this function. I think it would be simple to add:
https://svn.r-project.org/R/trunk/src/main/platform.c,
at line 1373, add "R_CheckUserInterrupt();" perhaps every some number of iterations if performance is a concern here.
Thanks,
Chris