[Bug 706553] context creation is not thread safe

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Aug 29 18:54:25 PDT 2013


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

--- Comment #5 from Matthew Waters <ystreet00 at gmail.com> 2013-08-30 01:54:16 UTC ---
(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.
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.
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.

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.  Option 2 would be next
on my list.  Option 3 and 4 would be last resorts.

> > Also, all of this could be moot when we stop creating threads to marshall GL
> > calls into.
> 
> That will probably be always there, no? Like for the video sink. Even if we
> don't do it for some contexts.

Hmm, now that I think about it, yes.  Even if we move the thread creation up
into glimagesink, the problem will still be there just not GstGLContext's
problem anymore :).

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