[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