[Bug 779181] gst_gl_window_eagl_new can be called multiple times in different threads, which can lead to deadlocks

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779181

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |ystreet00 at gmail.com

--- Comment #1 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to Nick Kallen from comment #0)
> Created attachment 346642 [details]
> Stacktraces
> 
> It says that 
> 
> /* Must be called in the gl thread */
> GstGLWindowEagl *
> gst_gl_window_eagl_new (GstGLDisplay * display)
> 
> However, it runs in the main thread if "gst_gl_basefilter_decide_allocation
> / ... / gst_gl_context_create / ... / _ensure_window" is called
> 
> Or if  "gst_glimage_sink_change_state / _ensure_gl_setup ... /
> _ensure_window" is called.

The comment could be old information, and honestly it probably is.

> And, in fact, these two things could run in multiple threads if queues and
> bins are involved and things are set in state playing before being linked
> together.

This sounds like a very bad idea without dealing with the ramifications like
this problem of having multiple GL context in the pipeline.  Also, do you deal
with the not-linked flow returns?  Negotiation?  This doesn't make sense.

There are fallbacks for the cases where two elements who want to share GL
context's aren't linked together but that requires them to be in the same
pipeline.

What's your pipeline? Do you have a test case that you can attach?  Preferably
reproducible on desktop as well. 

> This will lead to running this multiple times:
> 
>   gl_queue = dispatch_queue_create ("org.freedesktop.gstreamer.glwindow",
> NULL);
> 
> Which is bad, because when the elements are linked together the program will
> deadlock. I've attached a picture showing a deadlock. Note that their are
> two threads with the same name "org.freedesktop.gstreamer.glwindow", which I
> think should never happen.

There will be one dispatch queue per GL context created as the GL context needs
a GL thread provided by the window and to avoid context switching between
multiple GL contexts, they need their own threads.

> I think the fix is to EITHER make sure the window really is only called in
> the gl thread OR to make it use a singleton/static variable that is only
> initialized once.

Singleton is not possible due to above.

What do you mean by "window really is only called in the gl thread"?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.