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
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
