Hi there. I've run into a bit of a conundrum and I'm not quite sure how to proceed. This code intersects between Racket, C (through FFI), and Cocoa and I'm by no means an expert in any of those, so I'm hoping someone can help explain an odd set of bugs I'm seeing.
The main question I have is: How does racket/gui set up and interact with the NSApplication's main thread? I have some code that bridges Racket to GStreamer (http://gstreamer.freedesktop.org) via FFI: https://github.com/mwunsch/overscan For the purposes of this discussion, it will help to have that code nearby. Here's a small Racket program that uses the above-mentioned module to create a GStreamer pipeline using an osxvideosink (Objective-C source code for this element can be found here: https://github.com/GStreamer/gst-plugins-good/blob/master/sys/osxvideo/osxvideosink.m) I'm running this code in High Sierra, with the GST_DEBUG ENV variable set to "osxvideosink:5" #lang overscan (broadcast (videotestsrc) (element-factory%-make "osxvideosink")) This code seems to run fine. When I add a line above the broadcast call to (require racket/gui/base), the code will crash. Looking at the backtrace, I see that the crashed thread attempts to receive an event from a Core Foundation CFRunLoop and calls out to an observer callback function. My sense of this crash is that there's something inside the racket/gui internals (my hunch is that this code snippet is in the right neighborhood: https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/cocoa/queue.rkt#L288-L293) that works around a "typical" NSApplication start-up sequence that makes the osxvideosink code believe that it's running outside of the main NSApp thread. "Typical" is in quotes because I honestly have no idea what I'm talking about. Another example of this odd behavior is using the glimagesink (associated source code in this neck of the woods: https://github.com/GStreamer/gst-plugins-bad/blob/8d99867c13944be9ba75a892682204955f16f586/gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m#L332-L354) Running the code, but this time with GST_DEBUG set to "gl*:5" #lang overscan (require racket/gui/base) (broadcast (videotestsrc) (element-factory%-make "glimagesink")) For me, this code will display a window with a still video frame, and not animate beyond this. My hunch is, similar to the osxvideosink code, the glimagesink code expects frame updates to be enqueued on the main thread, but the creation of the racket/gui internals prevents these events from being dequeued. Can someone who has a better understanding of the Cocoa foundations (pun somewhat intentional) of racket/gui help me better understand why this code is behaving oddly, and what, if anything can be done to ensure that the application's main thread processes events (if that's the kind of thing that should be ensured)? Thanks for going down this rabbit hole. - Mark -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
