After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319871 - drop GIL state lock when doing something that can cause a property notify to be emitted
drop GIL state lock when doing something that can cause a property notify to ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-python
git master
Other Linux
: Normal normal
: 0.10.5
Assigned To: Edward Hervey
Johan (not receiving bugmail) Dahlin
Depends on:
Blocks:
 
 
Reported: 2005-10-26 16:46 UTC by Andy Wingo
Modified: 2006-07-02 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andy Wingo 2005-10-26 16:46:11 UTC 
The class lock that is taken in gstobject::dispatch_properties_changed can cause
deadlocks when doing emissions. Consider an application written in a language
that has to hold a global lock G at all times, and two objects A and B of type T.

Application thread: B.connect(my_func)
  Streaming thread: B.notify('foo')
  Streaming thread: T.lock() (via gstobject::dispatch_properties_change)
  Streaming thread: G.lock() (blocks until application thread drops G)
Application thread: A.set_property('foo')
Application thread: A.notify('foo') (via the gobject notify system)
Application thread: T.lock() (deadlocks)

The class lock is unnecessary for GLib 2.8 and so is not taken. However
something will have to be done for GLib 2.6. Assigning to Mr. Vander Stichele :)
Comment 1 Andy Wingo 2005-10-26 16:47:02 UTC 
(specifically: drop gil state lock when doing GObject.set_property() or
GObject.notify())
Comment 2 Edward Hervey 2005-11-22 20:41:35 UTC 
this isn't a gst-python bug, it's a pygtk bug. There's nothing we can do in
gst-python about uses of PyGObject API :(
Comment 3 Johan (not receiving bugmail) Dahlin 2005-11-22 20:43:24 UTC 
Edward: if you have a test case for PyGTK please let me know
Comment 4 Andy Wingo 2005-11-23 10:29:30 UTC 
Edward: sure you can't hack around this in gst-python for 2.6? It would require
overriding GstObject.set_property and GstObject.notify, so that they drop the
GIL lock while in the set_property or notify.
Comment 5 Edward Hervey 2005-11-26 11:34:56 UTC 
argh, another 2.6 hack... sure, I'll try to do that
Comment 6 Andy Wingo 2006-01-16 15:23:14 UTC 
You got a plan for this, Edward?
Comment 7 Edward Hervey 2006-01-17 15:55:51 UTC 
I have to add some stuff to configure.ac to figure out if we're compiling against glib/pygtk 2.6.
Then I can do some #ifdef'd sections of code with overrides for GstObject.set_property and GstObject.notify.

The problem with this is the check is only done at compile time.

So the other option would be always overridding those two methods... but I guess pygobject>=2.8 already does that.
Comment 8 Wim Taymans 2006-03-07 17:21:19 UTC 
ping?
Comment 9 Wim Taymans 2006-03-23 11:36:00 UTC 
ping2? lowering priority if nobody cares...
Comment 10 Andy Wingo 2006-03-24 09:29:20 UTC 
We could just require glib 2.8 for the python bindings
Comment 11 Edward Hervey 2006-05-05 10:57:42 UTC 
since gstreamer core has switched to glib >= 2.8 ,I think it's high time we do the same for gst-python and remove the 2.6 cruft
Comment 12 Edward Hervey 2006-07-02 15:32:39 UTC 
gst-python now requires glib >= 2.8.0

Marking bug as fixed.