[Bug 706553] context creation is not thread safe

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=706553
  GStreamer | gst-plugins-gl | git

--- Comment #7 from Matthew Waters <ystreet00 at gmail.com> 2013-09-02 02:46:13 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > Clean? not really. Solutions? A few.
> > 
> > 1. move to GMainLoop however this requires support from the backends.  Requires
> > lifting the GMainLoop integration from clutter or gdk for Cocoa.  The win32
> > backend is easy to implement and the others (x11 and wayland) already use
> > GMainLoop.
> 
> Do you think it is possible at all to integrate Cocoa with GMainLoop? I think I
> saw some code somewhere doing that but it wasn't beautiful at all.

It looks like it is possible from the gdk and clutter backends although not
pretty.  It seems that in a couple of places it relies on the default GMainLoop
however that may be easy to change.  From a quick glance they seem almost
identical so should work :). I'll run a diff on them later to see what is
different.

> > 2. add support for submitting functions before the main loop has started and
> > run them at the beginning of the loop.  GMainLoop allows this.  Would require a
> > gst_gl_window_send_message_async that doesn't wait for completion.
> 
> Can we make them async without waiting for completion at all?

With GMainContext? yes, simply call g_main_context_invoke.  With cocoa, you
would do performSelector:@selector(funcname) onThread:thread_id withObject:arg
waitUntilDone:NO.  That may break the autorelease pool alloc/release idiom we
currently use though :/.

> > 3. add api so that we can say 'yes we are going to run you really soon so you
> > should buffer all functions you get and run them in the loop later'
> > 4. spinlock by calling gst_gl_window_send_message with a function that changes
> > some value that we check.
> 
> Instead of a spinlock you can always use a GCond.

We are using a GCond and its not working :)

> > 
> > Personally, I think option 1 would be the best in the long run however I don't
> > have OS X anywhere so would be unable to work on this.
> 
> Agreed, that seems the most cleanest solution

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.