Skip to content

R-SIG-Mac Digest, Vol 261, Issue 2

5 messages · Michael Hall, Simon Urbanek, Duncan Murdoch

Original
Michael Hall
# 
You could maybe look at what the app shows on Activity Monitor. Is it doing anything? CPU, IO?

You can spin dump from there but I?ve never found that particularly revealing.
Duncan Murdoch
#
On 2024-12-11 3:43 p.m., Michael Hall wrote:
It's definitely still working.  The typical situation where I've seen 
this lately is when doing some web scraping with RSelenium.  Sometimes 
it takes 10 minutes to visit all the pages and find the info I'm after 
(not because it's a lot of downloading, it's because the site is very 
slow).

Normally my code prints status reports as it goes so I can tell what's 
happening in the console.  When things are in the broken state, those 
don't show up until everything is done.  But I can still see the 
controlled copy of Chrome visiting pages, so I know it hasn't crashed. 
It doesn't seem any slower, it's just that there are no updates in the 
console or responses to user interaction while the command is running.

Duncan Murdoch
Simon Urbanek
# 
The GUI only gets to update things if the user code allows it to process events. If the package you are using doesn't let R process the event loop or if it uses code that explicitly disallows it (e.g. for re-entrance reasons) then there is nothing the GUI can since both R and the GUI run on the main thread (macOS doesn't allow it otherwise) so the GUI only gets to respond if R relinquishes control.

Note that some actions in the GUI require R code evaluations so those will all bock until your code finishes, effectively freezing the GUI.

It would be nice to see what are the exact conditions - i.e., what is it that blocks the event loop, ideally some reproducible example to see if there is anything we can do about it in R itself.

Cheers,
Simon
Duncan Murdoch
#
On 2024-12-11 6:22 p.m., Simon Urbanek wrote:
I don't think it's RSelenium or another package keeping control for too 
long without allowing a return to R.  Most of the calls to it only take 
a few seconds to execute; it's just that my R code has a lot of them, so 
the R function takes 10 minutes to finish. There are lots of R 
statements being executed.

However, it could be a package that is telling R to stop the GUI from 
processing events, and then forgetting to restore things when done. 
Lately it has only happened while RSelenium was executing, so that 
suggests it may be the culprit, but I don't know how to trigger it so I 
can't put together a reproducible example.

It was happening about once in 100 sessions using RSelenium and hasn't 
happened again since I tried John Fox's app nap advice, but I haven't 
had 100 sessions since then.

I've just discovered one thing that might be related.  Normally if I 
execute a long running command in the console, the cursor moves to the 
next line as soon as it starts, and stays there until it's done. 
However, if I run `Sys.sleep(10)` I get the same symptoms as I described 
for the 10 seconds it executes.  The cursor never advances, and Esc 
doesn't interrupt it.  Things go back to normal at the end, so that's 
different from the broken state.

Duncan
4 days later
Duncan Murdoch
# 
Two new data points:

1.  The loss of event handling happened again today, so John Fox's 
suggestion to avoid AppNap was not sufficient.

2.  Sys.sleep(10) still produces the ignored events, but in the broken 
state, it doesn't recover at the end.

Duncan Murdoch