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

[Duncan Murdoch]

On 2024-12-11 6:22 p.m., Simon Urbanek wrote:
> 
> 
>> On Dec 12, 2024, at 10:00 AM, Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>>
>> On 2024-12-11 3:43 p.m., Michael Hall wrote:
>>>>
>>>> Message: 1
>>>> Date: Wed, 11 Dec 2024 12:25:42 -0500
>>>> From: Duncan Murdoch <murdoch.duncan using gmail.com>
>>>> To: R-SIG-Mac <R-SIG-Mac using r-project.org>
>>>> Subject: [R-SIG-Mac] R.app not handling events
>>>> Message-ID: <bdf048f1-b010-4845-a67a-f24edf6345be using gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>>
>>>> Every now and then R.app stops responding to various events while a
>>>> long-running command is executing.  I can't scroll the console to look
>>>> at earlier results, and I don't see partial results until the whole
>>>> computation is complete.  If I ask MacOS to switch to that window, it
>>>> won't come to the top (though clicking on it does bring it up, but I
>>>> need to be able to see part of it to do that).
>>>>
>>>> Once it finishes it returns to the console prompt and things look fine,
>>>> but the same thing happens during the next long-running command.
>>>>
>>>> This happens every now and then, but I haven't spotted the cause.  The
>>>> only solution I've found is to quit the session and restart it.
>>>>
>>>> Does anyone know what might be causing this, or a way to fix it without
>>>> ending the session?
>>>>
>>>> Duncan Murdoch
>>>>
>>> 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.
>>
>> 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.
>>
> 
> 
> 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.

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