[R-SIG-Mac] Threads in R.app?
Duncan Murdoch
murdoch.duncan at gmail.com
Thu Jul 24 03:35:24 CEST 2014
On 23/07/2014, 4:10 PM, Simon Urbanek wrote:
> On Jul 23, 2014, at 11:46 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>
>> As I've mentioned before, I'm seeing crashes in rgl when running in R.app. I'm starting to wonder if the Cocoa messages that my window receives are running in a different thread from the thread where the R console takes input, because it seems some changes are not happening in the expected order. Is this the case? Is there any way I can force the rgl window to have its messages received in the same thread?
>>
>
> Normally, all messages are on the main loop. Although apps can run separate threads, the OS loop is always on the main thread (that's why it's so delicate for us, because R also runs on the main thread so the two loops must be meshed together without blocking each other).
>
> Can you send me a reference to the issue, please? I'll try to find some spare cycles to look into it later this week.
Thanks for the offer. Here's how to trigger the bug:
The current rgl version on R-forge (rev 1122, downloadable as
http://download.r-forge.r-project.org/src/contrib/rgl_0.94.1118.tar.gz)
shows the bug pretty reliably if you do this:
# Open a new window by running this demo:
demo(subdivision)
# Now manually close that window by clicking on the x in the frame,
# and make the following call:
rgl.clear()
This should open a new window and clear it, but it usually tries the
clear the window that was just closed, and crashes.
Sometimes this takes another try (just close the blank window and run
rgl.clear() again), but usually not.
I wouldn't be surprised if this is nothing to do with a lack of
synchronization, because every time I make a change that might affect
that the bug remains. It could well be a simple error elsewhere, but I
really can't spot it when debugging.
Duncan Murdoch
More information about the R-SIG-Mac
mailing list