[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gstreamer-devel
Subject:    playbin about-to-finish signal thread locking
From:       Robert Rosengren <Robert.Rosengren () axis ! com>
Date:       2020-10-27 6:33:59
Message-ID: 1603780439003.17903 () axis ! com
[Download RAW message or body]

Hi,

I have observed a thread deadlocking problem in my application using playbin,  and \
having it connected to about-to-finish signal. From my application's perspective I \
need to protect data with mutex since the signal will run in a gstreamer thread while \
application otherwise use glib mainloop. 

So, if application mainloop currently holds mutex and trying to stop pipeline by \
setting to NULL state, at the same time as the signal callback is received trying to \
take same mutex. Internally in gstreamer there is also a mutex that both threads \
wants, the signal callback holds it while my application mainloop wants to take it.

Should it not be possible to use mutex from within about-to-finish callback? 

Internal gstreamer lock involved in gstpad:
#4  0xb6d71f9e in post_activate (new_mode=GST_PAD_MODE_NONE, pad=0x15c5a10) at \
../gstreamer-1.16.2/gst/gstpad.c:1046

Kind of simple to trigger in a small application, just add g_idle_add from \
about-to-finish callback with a function that takes a mutex and tries to set NULL \
state, and make sure callback waits for it to happen and then take same mutex :)

Any ideas? Is it a bug in gstreamer not unlocking before calling signal callback, or \
my application is doing something it shouldn't?

Thanks and regards,
Robert
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


[prev in list] [next in list] [prev in thread] [next in thread]