On 23/07/2014, 4:10 PM, Simon Urbanek wrote: > On Jul 23, 2014, at 11:46 AM, Duncan Murdoch <[email protected]> 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 _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
