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 
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 
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: 
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 
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.

Reply via email to