[Bug 706553] context creation is not thread safe

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Aug 30 01:38:01 PDT 2013


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

--- Comment #6 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-08-30 08:37:53 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > IMHO this reduces the usefulness of the run/quit counter/flag option and leaves
> > > us with unlocking the render_lock when the loop actually runs.
> > 
> > Ack, do you see a clean solution for this that doesn't introduce new race
> > conditions? :)
> 
> 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.

> 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?

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

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

> Option 2 would be next on my list.  Option 3 and 4 would be last resorts.

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


More information about the gstreamer-bugs mailing list