[Rd] Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?
urbanek at research.att.com
Fri Feb 11 23:11:56 CET 2005
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...
More information about the R-devel