[Rd] Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?

[Simon Urbanek]

Brian,

On Feb 11, 2005, at 4:14 PM, Prof Brian Ripley wrote:

> The problem rather is that if R_CheckUserInterrupt is so expensive, we 
> need to redesign it, for it should not be

I agree, that's why I named it a 'quick fix'. Unfortunately a more 
'proper' fix is far from trivial.

Talking of handling interrupts alone, at a first glance Mac OS doesn't 
need a specific flag like Win, because it handles SIGINT like other 
unices (in fact that's the default if aqua is disabled). But at the 
second glance the issue is more tricky: although it is still possible 
to use the same check as on other unices, which allows anyone to 
interrupt R using SIGINT, we actually want some GUI element to trigger 
this - and we get response from GUI elements only if we run the system 
loop. So checking the interrupt flag is not expensive, but running the 
loop to enable GUI elements to set the flag is expensive. Currently we 
don't use threads in the GUI to ensure stability (other than for 
reading/writing pipes), so the system loop is embedded in the REPL, 
hence the "Stop" button (which in fact just sends SIGINT when 
triggered) doesn't work unless we run the system loop ...

I have an experimental version of the GUI that runs REPL and system 
loop in separate threads, but there are many issues, predominantly 
because the Application Framework is not thread-safe. Using distributed 
objects to circumvent this has quite big impact on performance, 
especially for the graphics device, so I'm not ready to do that step 
with the current public GUI yet.

I'll dig a bit to see whether I can come up with some way to get GUI 
response squeezed in without R_ProcessEvents somehow, but for the time 
being the quick fix is the only concrete solution I can offer...

Best,
Simon